Security - Using Components With Known Vulnerabilities
https://www.owasp.org/index.php/OWASP_Dependency_Check
https://www.owasp.org/index.php/ASVS_V1_Architecture
https://www.owasp.org/index.php/OWASP_Dependency_Check
https://www.owasp.org/index.php/Map_Application_Architecture_(OTG-INFO-010)
https://www.owasp.org/index.php/Virtual_Patching_Best_Practices
https://www.cvedetails.com/version-search.php
https://nvd.nist.gov/
https://github.com/retirejs/retire.js/
https://nodesecurity.io/advisories
https://rubysec.com/
// Security - Using Components with Known Vulnerabilities:
Unfortunately, vulnerability reports for commercial or open source software do
not always specify exactly which versions of a component are vulnerable in a
standard, searchable way. Further, not all libraries use an understandable
version numbering system. Worst of all, not all vulnerabilities are reported to
a central clearinghouse that is easy to search, although sites like CVE and NVD
are becoming easier to search.
Determining if you are vulnerable requires searching these databases, as well as
keeping abreast of project mailing lists and announcements for anything that
might be a vulnerability. If one of your components does have a vulnerability,
you should carefully evaluate whether you are actually vulnerable by checking to
see if your code uses the part of the component with the vulnerability and
whether the flaw could result in an impact you care about.
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.
http://mojo.codehaus.org/versions-maven-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
page revision: 2, last edited: 29 Jul 2018 02:55