18

In this iteration of the OWASP top 10 application security vulnerabilities list (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), a new category 'A9 Using Components with Known Vulnerabilities' has been introduced. This appears to require the investigation of all libraries and imported code in any application to ensure compliance.

I have a number of clients who, because of their PCI-DSS audit requirements, use the OWASP top 10 to ensure the security of their own software platforms for those portions of their code base written to process credit card payments. With this new set of requirements it would appear that they would have to find/list all of their imported libraries (Perl modules from CPAN in one instance, and Java libs in another) and go through them line by line - probably a million lines of someone else's code!.

This can't be practical or, probably, very useful! Can OWASP seriously be suggesting that those organisations that write their own applications, importing common libraries, have to review all third-party library code?

Has anyone else come across this problem, and how do you think I can deal with this?

rook
  • 46,916
  • 10
  • 92
  • 181
David Scholefield
  • 1,824
  • 12
  • 21
  • Note that the list changes every year, so you have to specify *which version* you're referring to if you just give the number – tylerl Nov 26 '13 at 02:20
  • @tylerl Every *three* years, but your point is valid. – Rap Aug 03 '15 at 18:52

3 Answers3

27

In a formal review of an application's security, all libraries should be vetted for security defects. However, this is not the point of OWASP-2013 A9. The core of OWASP-2013 A9 is about having a policies in place to ensure that an application isn't compromised due to negligence. OWASP states the following:

  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.

Number 2 is the most important. If you are dependent on a library or platform, these components need to be updated regularly. Internally there should be a cycle to review all components and versions, and ensure that these are fully updated. A monthly cycle to review these components would be ideal.

In short number 4 is requiring strong validation of input to untrusted libraries. If a library hasn't been fully tested for security defects then data passed to this library must be validated. It is a very good security practice to do this for all input. An example of this is using an OWASP ESAPI validation routine for all input. So if it is an email address, it should match a regex for email addresses.

rook
  • 46,916
  • 10
  • 92
  • 181
  • 1
    that sounds more reasonable, but do you think there is some more formal commentary from OWASP or someone else with 'gravitas' that could be used when the auditor asks about this requirement? I saw the point you've highlighted, but 3, and *especially* 4 can only be done if you review the actual code i.e how can you add security wrappers to 'secure weak or vulnerable aspects of the component' if you don't look inside and review what the code actually does? – David Scholefield Sep 22 '13 at 18:38
  • @David Scholefield Updated, i added information about #4 – rook Sep 22 '13 at 19:31
4

From an auditor's point of view, I do not expect you to go through every single line of code of used libraries IF the library is commonly used and vetted. If you are using "random code you found on the internet" for a transaction system then I expect you to have had a review on the code.

Now for the more used and vetted libraries I would simply review the version of the library and see if there are any known vulnerabilities. You should regularly update your libraries with at least every single security update.

If no security update is available for the issue, I would require you to have an action plan to:

  • monitor if exploitation has happened (sometimes a security update can be for a component which is not used)
  • mitigation of the risk (disabling the component or altering the WAV/IPS)
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
0

Rook provided a great answer to your question - and while it is certainly easier to monitor the components using public databases and other means vs. reviewing the code for all components, it's still a major undertaking. Why? Because applications are now comprised primarily of components - research shows that an average application now consists of 80% or more open source components. And, it's not just about the components that you pull in to your application, it also includes all of the other dependent components. Given the volume, variety and release cadence (many projects are updated 4 times per year), some form of automation is necessary.

Existing application security technologies like DAST and SAST are designed for a different problem - they are focused on the custom code that glues the components together. A different approach is needed to keep up - an approach that governs the entire lifecycle, vs. point in time scans that are delivered late in the development cycle.

There are 2 whitepapers available that provide more background on OWASP A9 and the new PCI 3.0 component requirements. In addition, an webinar on this topic that includes information from Crosskey, a financial services firm, is also available.

http://www.sonatype.com/resources

Thanks, Mark Troester Sonatype @mtroester

user34678
  • 1