In a formal review of security all libraries should be vetted for security defects. However, this is not the point of OWASP-2013 A9. 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.

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.

In a formal review of security all libraries should be vetted for security defects. However, this is not the point of OWASP-2013 A9. 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 a formal review of security all libraries should be vetted for security defects. However, this is not the point of OWASP-2013 A9. 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.