A9 Using Components with Known Vulnerabilities

A9 Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

A9.1 Best Practices

Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. So upgrading to these new versions is critical. Software projects should have a process in place to:

1. Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).
2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
4. Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.

A 9.2 Tools:

OWASP Dependency Check (for Java libraries)

OWASP Dependency check, maven plugin, ant task, Jenkins integration

RetireJS – exclusive for JavaScriptFind bugs with security, IDE plugin: support for Eclipse, Maven, Jenkins, Sonar QubeSonatype – Nexus Firewall for scanning new and existing components

Learn More:

• OWASP Dependency Check (for Java libraries) 
• OWASPSafeNuGet  (for .NET libraries) 
• OWASP Good Component Practices Project 
• The Unfortunate Reality of Insecure Libraries 
• Open Source Software Security 
• Addressing Security Concerns in Open Source Components 
• MITRE Common Vulnerabilities and Exposures 
• Example Mass Assignment Vulnerability that was fixed inActiveRecord, a Ruby on Rails GEM