Devbridge is officially transitioning to the Cognizant brand at the end of 2023. Come visit us at our new home as part of the Cognizant Software Engineering team.
White Paper

Documented standards for secure product development

A downloadable Security Handbook to document our best practices

Download white paper

9. Components with known vulnerabilities

Known vulnerabilities are found and exploited before they are fixed.

What it is

When vulnerabilities become known, vendors generally fix them with a patch or update. The process of updating the software should eliminate or mitigate a specific vulnerability. Component-heavy development patterns can lead to development teams not understanding which components they use in the application or API, much less keeping them up-to-date.

How it works

Organizations sometimes fail to keep software up-to-date, especially when stacks are large or complex or require a significant undertaking to validate systems or products after an update. When an exploit is made public, or a patch is released, attackers know that some organizations do not act immediately. Hackers now have a window, ranging from days to years, to search for systems or applications for known vulnerabilities left unaddressed.

Why it’s bad

As CVEs and security bulletins are public information, attackers have a recommended path to exploit vulnerabilities. Organizations have little excuse for leaving the path open.

Countermeasures

  • Remove unused dependencies, unnecessary features, components, files, and documentation.

  • Fix and upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion.

  • Use software composition analysis tools to automate the process of monitoring systems for vulnerabilities published in CVE and NVD lists.

  • Only obtain components from official sources over secure links.

  • Prefer signed packages to reduce the chance of including a modified, malicious component.

  • Avoid libraries and components that are unmaintained or do not create security patches for older versions.

  • Secure the components' configurations by applying countermeasures for security misconfiguration.

Components with known vulnerabilities example 1

Code libraries, framework, and component exploits occur.

Coding involves the use of open-source libraries, frameworks, and components from trusted sources. Problems arise when trusted sources can no longer be trusted. Verifying all dependency libraries and ensuring any known vulnerabilities go unresolved when upgrades, patches, or fixing to a specific version of the component using a private binary repo would help.

Component vulnerabilities 1

NPM install <package name>

Component vulnerabilities 2

Components with known vulnerabilities example 2

The discovery of the Heartbleed vulnerability represented a turning point for OpenSSL with attackers using an OpenSSL session.

Typically, a session uses in a normal call for the word “blah” and four letters. However, in an attack, the OpenSSL exploit allows a hacker to ask for additional 3996 letters, enabling the server to expose additional data.

Component vulnerabilities 3

Continue to:10. Insufficient logging & monitoring