Press Release
Last Updated on January 4, 2024
70% of applications have open source security flaws, according to recent Veracode research.
Virtually all applications developed are built using some open source components. As Chris Eng, Chief Research Officer at Veracode, notes, “Open source software has a surprising variety of flaws. An application’s attack surface is not limited to its own code and the code of explicitly included libraries, because those libraries have their own dependencies.”
When Chris refers to dependencies, he is talking about a software supply chain challenge. In other words, the flaws are not pulled in directly by developers, but are being pulled in by upstream libraries.
How can you minimize this risk?
Design and/or validate the application leveraging OWASP Application Security Verification Standard (ASVS) Level 2 guidance.
OWASP addressees this vulnerability in the Configuration Verification Requirements Domain (V14), which is intended to ensure that a verified application has:
- A secure, repeatable, automatable build environment
- Hardened third-party library, dependency and configuration management such that out-of-date or insecure components are not included by the application
- A secure-by-default configuration, such that administrators and users have to weaken the default security posture.
Configuration of the application out-of-the-box should therefore be safe to be on the Internet.
The ASVS does this specifically by establishing a number of requirements, including:
- Verify that third-party components come from pre-defined, trusted and continually maintained repositories
- Verify that an inventory catalog is maintained of all third-party libraries in use
- Verify that the attack surface is reduced by sandboxing or encapsulating third-party libraries to expose only the required behavior into the application
One more reason why we are such strong advocates of the ASVS: with the relatively minimal effort just described, you can significantly reduce your application’s threat exposure.
