PT0-002 · Question #21
A penetration tester has completed an analysis of the various software products produced by the company under assessment. The tester found that over the past several years the company has been…
The correct answer is A. Add a dependency checker into the tool chain. The root cause identified is vulnerable third-party/open-source dependencies, not flaws in the company's own code. A dependency checker (such as OWASP Dependency-Check, Snyk, or GitHub Dependabot) integrated into the CI/CD pipeline will automatically detect when a third-party…
Question
A penetration tester has completed an analysis of the various software products produced by the company under assessment. The tester found that over the past several years the company has been including vulnerable third-party modules in multiple products, even though the quality of the organic code being developed is very good. Which of the following recommendations should the penetration tester include in the report?
Options
- AAdd a dependency checker into the tool chain.
- BPerform routine static and dynamic analysis of committed code.
- CValidate API security settings before deployment.
- DPerform fuzz testing of compiled binaries.
How the community answered
(38 responses)- A82% (31)
- B5% (2)
- C11% (4)
- D3% (1)
Explanation
The root cause identified is vulnerable third-party/open-source dependencies, not flaws in the company's own code. A dependency checker (such as OWASP Dependency-Check, Snyk, or GitHub Dependabot) integrated into the CI/CD pipeline will automatically detect when a third-party library has a known CVE, alerting developers before vulnerable components ship. Static and dynamic analysis (B) addresses organic code quality, which is already strong. API security validation (C) and fuzz testing (D) do not specifically target the dependency vulnerability problem.
Topics
Community Discussion
No community discussion yet for this question.