In 2024 an engineer reported a backdoor on the oss-security mailing list. IT was a compression library used across Linux and other Unix-like systems. The flaw scored 10 on the Common Vulnerability Scoring System (CVSS), the highest rating possible. Attackers planted the malicious code in the upstream release tarballs, not in the project’s normal source, and it was injected into liblzma during the build.
If you sign off applications through secure code review, this case applies to you. A review examines the code your developers wrote. But it does not examine the libraries, packages and vendor components that ship with that code.
In most modern applications, those components make up the larger share of what runs in production. A clean review report is accurate but incomplete. This blog shows where secure code review stops, what third-party components can still expose and how a Software Bill of Materials (SBOM) closes the gap.
What secure code review covers, and where it stops
You might read a clean review as proof that an application is safe. In reality, the review does not make that claim. Knowing its boundary is the first step to governing what sits beyond it.
What reviewers examine
A secure code review tests the logic your team built. Reviewers combine static analysis tools with manual inspection. They look for injection, broken authentication, weak authorisation checks and unsafe business logic. Many serious flaws show up only when a reviewer understands what the code is meant to do.
Why third-party code sits outside the brief
Review scope usually follows the repository your team maintains. Open-source libraries arrive at build time and vendor components often come as compiled binaries with no source to read. A reviewer may note that a library is in use, but auditing its internals is rarely part of the engagement.
A sign-off is a verdict on one day
New vulnerabilities are published against existing components every week. An application that was clean on review day can be exposed a month later without a single line of your code changing. The report stays the same while the risk moves. Ask each reviewer to state in writing what the engagement did not cover.
What third-party components can still expose after a clean review
Open source appears in 98% of the commercial codebases audited in Black Duck’s 2026 Open Source Security and Risk Analysis report. Four risk areas stand out.
1. Known vulnerabilities in direct and transitive dependencies
A transitive dependency is a library your code never calls directly. It arrives because another library needs it. The audit found that the average number of open-source vulnerabilities per codebase more than doubled to 581. Of the codebases audited, 44% contained critical-risk issues.
2. Components that bypass package managers
Some third-party code appears in no dependency file. The audit found that 17% of open-source components enter codebases outside standard package managers. They arrive as copied snippets, direct vendor inclusions or AI-generated code. Tools that read manifests cannot see them.
3. Build outputs that differ from reviewed source
The case we discussed earlier is the clearest example. The backdoor lived in the packaged release, not in the source most people would inspect. Source review cannot confirm what the build produced. Only an inventory of the built artefact can.
4. Licence conflicts, end-of-life components and weak cryptography
Licence risk is separate from vulnerability risk. Two-thirds of audited codebases had open-source licence conflicts, up from 56% the year before.
End-of-life components stop receiving fixes. Some libraries also carry outdated cryptography, such as RSA-1024 keys or old Transport Layer Security versions. Treat these four areas as a standing checklist. For each application, know which ones you can answer with evidence today.
Why this gap is now an audit question for regulated entities
For banks, brokers and asset managers in India, third-party component risk now reaches the audit room. Regulators expect you to show what you run.
Regulatory scope is wider than review scope
The Securities and Exchange Board of India (SEBI) Cybersecurity and Cyber Resilience Framework (CSCRF) requires an SBOM for all core and critical business software. That covers in-house, third-party, legacy and SaaS applications. CSCRF also expects you to update the SBOM with every upgrade or change. A review scoped to one repository at one point in time cannot meet that expectation alone.
Auditors ask what shipped
The Indian Computer Emergency Response Team (CERT-In) guidelines list 21 fields an SBOM should capture. SEBI specifies nine. The Reserve Bank of India has advised its regulated entities to adopt the CERT-In SBOM guidelines. An auditor will ask for a component inventory, supplier details and licence data. A code review report contains none of these.
The cost of “we are still checking”
When a critical vulnerability is disclosed, leadership asks one question: are we affected? Without a current component inventory, the answer means manual searches across teams and vendors. Run one test. Pick a widely used library and time how long it takes to list every application that contains it.
How SBOM and secure code review work together
An SBOM does not replace code review. Code review asks whether the code you wrote is sound, whereas an SBOM records everything that shipped with it.
The SBOM gives reviewers a map of the build
An SBOM is a machine-readable inventory of every component in an application, including transitive dependencies. Hand it to reviewers at the start of the engagement. It shows which libraries the application relies on most and which carry known issues. Reviewers can then focus on the points where third-party code meets your own logic.
Code review confirms reachability
A vulnerable library is not always an exploitable one. The question is whether your application calls the vulnerable function with input an attacker controls. When that path exists, the component is reachable. Reviewers can confirm or rule it out. Their answer turns a long list of findings into a short list of real priorities.
Continuous monitoring covers the months after sign-off
The SBOM keeps working after the review ends. You can match new disclosures against the inventory as they are published. A component that was clean at sign-off gets flagged the day it becomes a risk.
A practical starting plan for your next release
You can start closing this gap in your next release. Three changes are enough.
1. Generate the SBOM at build time
Produce the SBOM inside your continuous integration and delivery pipeline in a standard format such as CycloneDX or SPDX. An inventory generated from the build reflects what ships.
2. Add component findings to the review report
Ask reviewers to add a short section on third-party components. It should list which vulnerable components they checked for reachability and what they concluded. You get one record for security teams and auditors.
3. Set re-review triggers from SBOM changes
Agree on the changes that prompt a fresh look. Typical triggers include a new critical vulnerability in a reachable component, a new direct dependency in a sensitive module or a component reaching end of life. Review effort then follows risk, not the calendar.
Conclusion
Secure code review remains one of the best ways to find flaws in the logic your team builds. It certifies the code you wrote on the day it was reviewed. The libraries and vendor components around that code need their own inventory and monitoring. Our SBOM solutions build it from source, binaries and containers, maps it to CERT-In and SEBI fields and monitors it after every sign-off. Speak with our team to map your third-party exposure, application by application.
FAQs
Does secure code review cover open-source libraries?
Usually not in depth. Reviewers may note which libraries are in use but rarely audit their internals. Pair the review with a component inventory and continuous vulnerability matching.
Do in-house applications need an SBOM under SEBI CSCRF?
Yes, if they are core or critical business software. SEBI’s clarifications cover in-house, third-party, legacy and SaaS applications.
What is the difference between static analysis and software composition analysis?
Static analysis examines your own source code for insecure patterns. Software composition analysis identifies the third-party components in an application and checks them against known vulnerabilities and licences. Most organisations need both. Read our blog on SBOM vs SCA.
