Security - Using Components With Known Vulnerabilities

security

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
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License