A licence detection method that inspects the actual source code or package contents for licence files, headers, and embedded licence text. It is slower than metadata lookup, but it provides stronger evidence because it can find obligations that are not visible in registry metadata alone.
Expanded Definition
Direct code analysis is a deeper software licence review method that examines the codebase or distributed package itself, rather than relying only on repository metadata, manifests, or package registry summaries. It looks for embedded licence text, copyright headers, licence files, and other in-band indicators that may reveal obligations a metadata-only scan can miss. For open source governance, this matters because licence terms are often attached to the distributed artefact, not just the package name. As a result, direct code analysis is typically used when teams need higher confidence before release, redistribution, or incorporation into a larger product. Guidance varies across tools and vendors on what qualifies as sufficient evidence, so organisations should treat it as a verification method rather than a simple yes or no lookup. The most common misapplication is assuming registry metadata is authoritative, which occurs when teams approve a dependency without checking the package contents for embedded licence notices.
Examples and Use Cases
Implementing direct code analysis rigorously often introduces review overhead and slower build pipelines, requiring organisations to weigh assurance against delivery speed.
- Scanning a third-party library for a COPYING file or inline licence header before approving it for internal use.
- Reviewing a source distribution tarball to confirm whether licence text is bundled with the code, as recommended by source-review practices in the NIST SP 800-53 Rev 5 Security and Privacy Controls supply-chain and governance context.
- Checking a vendored dependency in a monorepo after a package manager import removed or obscured original metadata.
- Validating that generated artefacts or copied snippets still carry attribution and licence notices after build-time transformation.
- Comparing direct file inspection results with SBOM or registry data when licence statements conflict or appear incomplete.
Why It Matters for Security Teams
Security teams care about direct code analysis because licence obligations can create legal, operational, and release risk when they are discovered too late. A dependency that looked permissive in metadata may in fact contain restrictive terms in the distributed source, which can affect redistribution rights, notice requirements, and product packaging decisions. In software assurance workflows, this becomes part of broader control validation alongside inventory, provenance, and change management. It also supports stronger software supply chain governance by helping teams confirm what is actually being shipped, not just what a registry claims. For organisations operating in regulated environments, that level of evidence can be important when demonstrating disciplined control over third-party components and build outputs. It also intersects with broader cybersecurity governance where code provenance and artefact integrity affect trust in the software lifecycle. Organisations typically encounter licence non-compliance only after a release, audit, or customer escalation, at which point direct code analysis becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022, PCI DSS v4.0 and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | Supply chain governance covers review of third-party software components and their obligations. |
| NIST SP 800-53 Rev 5 | SA-15 | This control family supports acquisition and development review of software and source provenance. |
| ISO/IEC 27001:2022 | ISO 27001 supports supplier and asset governance relevant to software obligations and evidence. | |
| PCI DSS v4.0 | 6.3.2 | Secure software development requires validating third-party code before deployment in cardholder environments. |
| NIS2 | NIS2 raises expectations for secure development and supply-chain risk management across operators. |
Require source-level checks for embedded licence notices as part of software acquisition and development.
Related resources from NHI Mgmt Group
- What is the difference between SAST and semantic AI code analysis?
- What breaks when an AI agent moves from bug analysis to code modification?
- How do security teams know whether semantic code analysis is actually working?
- How should security teams choose between semantic code analysis and AST-based scanning?
