R262. Verify third-party components


The system must use stable, tested and up-to-date versions of third-party components.


  1. The organization must ensure that the version of all of its products and the products provided by third-parties is up to date, stable and tested. This reduces the risk of including vulnerabilities reported in previous versions.

  2. When a product changes its version, the implemented improvements must be checked to verify if there were fixes or new controls related to recently discovered vulnerabilities.


  1. Identify all the products that compose the technology stack, including operating systems, versions, dependencies, and logical and physical authentication features. This inventory must be constantly updated.

  2. Monitor the security of all identified components in public databases, implementing alerts when public vulnerabilities are disclosed for the products used by the organization and determining the affectation level caused by the reported vulnerabilities.

  3. Apply the necessary updates taking into account the vulnerability type, the affected components and its risk classification within the organization.

  4. Define security policies for the used components, requiring updated versions, specific software, ethical hacking and product licenses. Include internal policies to disable unused features and update default settings that may pose a risk to the organization.


  1. An attacker obtains technical information about a specific product. If the service/software is out of date, there could be public exploits designed to attack known vulnerabilities present in the in-use version of the product.


  1. Layer: Application layer

  2. Asset: Services and functions

  3. Scope: Stability

  4. Phase: Operation

  5. Type of control: Recommendation


  1. BSIMM9 SR2.4: 60. Identify open source. Organizations use a variety of tools and metadata provided by delivery pipelines to discover old versions of components with known vulnerabilities or that their software relies on multiple versions of the same component.

  2. CAPEC-42: MIME Conversion. An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail.

  3. CAPEC-240: Resource Injection. An adversary exploits weaknesses in input validation by manipulating resource identifiers enabling the unintended modification or specification of a resource.

  4. CAPEC-242: Code Injection. An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing.

  5. CIS Controls. 2.4 Track Software Inventory Information. The software inventory system should track the name, version, publisher, and install date for all software, including operating systems authorized by the organization.

  6. CIS Controls. 3.5 Deploy Automated Software Patch Management Tools. Deploy automated software update tools in order to ensure that third-party software on all systems is running the most recent security updates provided by the software vendor.

  7. CIS Controls. 18.3 Verify That Acquired Software Is Still Supported. Verify that the version of all software acquired from outside your organization is still supported by the developer or appropriately hardened based on developer security recommendations.

  8. CIS Controls. 18.4 Only Use Up-to-Date and Trusted Third-Party Components. Only use up-to-date and trusted third-party components for the software developed by the organization.

  9. CWE-507: Trojan Horse. The software appears to contain benign or useful functionality, but it also contains code that is hidden from normal operation that violates the intended security policy of the user or the system administrator.

  10. ISO 27001:2013. Annex A - 12.6.1 Gather timely information regarding technical vulnerabilities in information systems in use.

  11. OWASP Top 10 A9:2017-Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

  12. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.13) Verify all code including third-party binaries, libraries, frameworks are reviewed for hardcoded credentials (backdoors).

  13. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.26) Verify that only micro controllers that support disabling debugging interfaces (e.g., JTAG, SWD) are used.

  14. OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.27) Verify that only micro controllers that provide substantial protection from de-capping and side channel attacks are used.

  15. OWASP-ASVS v4.0.1 V1.14 Configuration Architectural Requirements.(1.14.1) Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.

  16. OWASP-ASVS v4.0.1 V10.2 Malicious Code Search.(10.2.1) Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user’s permission for it to operate before collecting any data.

  17. OWASP-ASVS v4.0.1 V10.2 Malicious Code Search.(10.2.3) Verify that the application source code and third party libraries do not contain backdoors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.

  18. OWASP-ASVS v4.0.1 V10.2 Malicious Code Search.(10.2.4) Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.

  19. OWASP-ASVS v4.0.1 V10.2 Malicious Code Search.(10.2.5) Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.

  20. OWASP-ASVS v4.0.1 V10.2 Malicious Code Search.(10.2.6) Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.

  21. OWASP-ASVS v4.0.1 V14.2 Dependency.(14.2.1) Verify that all components are up to date, preferably using a dependency checker during build or compile time.

  22. OWASP-ASVS v4.0.1 V14.2 Dependency.(14.2.4) Verify that third party components come from pre-defined, trusted and continually maintained repositories.

  23. PCI DSS v3.2.1 - Requirement 5.2 Ensure that all anti-virus mechanisms are kept current.

  24. PCI DSS v3.2.1 - Requirement 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches.

Service status - Terms of Use - Privacy Policy - Cookie Policy

Copyright © 2021 Fluid Attacks, We hack your software. All rights reserved.