Modern enterprises rarely acquire software as a self-contained product. A business application may combine internally developed code, open-source libraries, commercial components, outsourced modules, cloud services, infrastructure code, build tools, and increasingly, code produced or modified with AI.
That makes software risk difficult to evaluate from the outside.
A vulnerability scan can identify known weaknesses. An SBOM can identify components. A code review can examine changes. A penetration test can expose exploitable behavior. But none of these, individually, establishes whether an entire software asset is secure, maintainable, governable, explainable, and fit for its intended business purpose.
The problem becomes more pronounced during acquisitions, vendor selection, modernization programs, outsourcing transitions, and technology portfolio reviews. A company may inherit a codebase without understanding who owns its dependencies, how it is built, which components are obsolete, how much technical debt it contains, or whether the production artifact can be traced back to trusted source material.
NIST’s Secure Software Development Framework explicitly recognizes that software consumers and purchasers need security-development evidence when evaluating suppliers and acquisition decisions.
The central challenge is therefore not simply finding vulnerabilities. It is establishing evidence.
That evidence can be organized as a Software Risk Evidence Chain:
Code
↓
Dependencies
↓
Provenance
↓
Architecture
↓
Security
↓
Quality
↓
Ownership
↓
Governance
↓
Business Risk
The objective is not to turn executives into developers. It is to give them a disciplined way to ask what the technical evidence means, what remains unknown, and what decision should follow.
Seven findings frame the modern software-risk problem:
Vulnerability counts are only one dimension of software risk. A system can have few known CVEs while still carrying architecture, maintainability, provenance, licensing, operational, or governance risks.
Dependencies create indirect exposure. Direct and transitive dependencies can introduce security, availability, licensing, and support obligations that the software owner did not explicitly build.
Provenance determines how much confidence can be placed in other evidence. SLSA defines provenance as verifiable information describing where, when, and how software was produced.
Architecture and technical debt influence software value. High coupling, unsupported technologies, poor testing, and architecture drift can increase future ownership and modernization costs even when the software works today.
AI-generated code adds an assurance dimension. AI coding tools can accelerate development, but generated output still requires human review and testing; GitHub explicitly recommends treating Copilot as a tool rather than a replacement for programming judgment.
Ownership and governance convert technical findings into organizational action. An identified risk without a responsible owner, remediation process, or decision threshold remains an unmanaged exposure.
Software assurance is becoming continuous. Modern supply chains change through dependency updates, automated builds, AI-assisted modifications, infrastructure changes, and frequent releases. CISA and CNCF guidance therefore emphasizes maintaining current inventories, tracking changes, validating dependencies, and monitoring the supply chain over the software lifecycle.
What Is Software Risk?
Software risk is the possibility that a software asset will fail to meet its security, operational, architectural, legal, financial, maintainability, or governance requirements. It includes known vulnerabilities but also risks created by dependencies, poor architecture, unclear ownership, weak provenance, technical debt, licensing obligations, and insufficient evidence about how the software is produced and maintained.
Software risk is multidimensional.
| Risk type | What it means | Executive question |
|---|
| Vulnerability risk | Known weaknesses that may be exploitable | What known weaknesses could materially affect us? |
| Security risk | Broader exposure created by design, configuration, access, and implementation | Could the system be compromised even without a known CVE? |
| Architecture risk | Structural limitations that make change, scaling, or integration difficult | Can the system evolve without disproportionate cost? |
| Dependency risk | Exposure created by components the organization relies upon | What happens if a dependency becomes vulnerable, unsupported, or unavailable? |
| Provenance risk | Uncertainty about where code or artifacts came from and how they were produced | Can we establish the origin and integrity of what we are running? |
| Licensing risk | Obligations associated with software components and their licenses | Can we legally use, modify, distribute, or commercialize this software as intended? |
| Maintainability risk | Difficulty keeping the software reliable and supportable | Can another team realistically operate and change it? |
| Operational risk | Conditions that threaten availability, recovery, observability, or deployment | Can the organization operate the software reliably? |
| Governance risk | Lack of ownership, controls, policies, evidence, or accountability | Who is responsible for this software and its risks? |
The distinction matters because a technical signal is not itself a business consequence.
For example, “high coupling” is a technical signal. The business interpretation might be “a seemingly small product change could require coordinated changes across multiple services, increasing delivery time and regression risk.”
Likewise, “unmaintained dependency” is not merely a package-management observation. It may indicate that future security patches, compatibility fixes, or support will require migration to another component.
Software risk is the gap between what an organization requires from software and what its technical, operational, and governance evidence can demonstrate.
Why Software Can Be Risky Even When It Has No Known Vulnerabilities
A clean vulnerability report does not establish that software is low risk. Vulnerability scanners primarily identify known security weaknesses within their coverage. They do not automatically establish maintainability, architecture quality, provenance, ownership, licensing compliance, dependency health, configuration quality, test adequacy, or operational resilience.
Consider a codebase containing an abandoned library with no currently published CVE.
The immediate security scan may report nothing critical. Yet the organization may have no maintainer to contact, no supported upgrade path, and no assurance that future vulnerabilities will be patched. OWASP’s 2025 Software Supply Chain Failures category explicitly expands the concern beyond known vulnerabilities to include unmaintained components, unsupported software, transitive dependencies, weak change management, untrusted sources, and insecure CI/CD environments.
Other risk signals include:
Unknown or transitive dependencies
Hard-coded secrets
Insecure defaults
Weak authentication design
Architecture coupling
Poor test coverage
Undocumented business logic
Repository fragmentation
Build-time dependencies
Configuration dependencies
License obligations
Unclear code ownership
Unsupported frameworks
Weak deployment processes
This creates an important distinction:
Known defect
≠
Known risk
≠
Complete software assurance
A scanner finding “zero critical vulnerabilities” is evidence about one question. It is not evidence that all other questions have been answered.
For an acquisition team, the difference can affect valuation and integration planning. For procurement, it can affect vendor risk. For operations, it can affect resilience. For security teams, it can create remediation uncertainty. For boards, it can create uncertainty about whether the technology asset being acquired is actually supportable.
The absence of known vulnerabilities is evidence of limited scope, not proof of low overall software risk.
How AI-Generated Code Changes Software Risk
AI-assisted development changes software assurance because organizations can now generate, modify, refactor, and test code through systems that may operate at much greater speed than traditional human-only development. The resulting code is not inherently insecure, but organizations need stronger evidence about its origin, review, testing, dependencies, and approval.
AI coding assistants, pair-programming systems, autonomous coding agents, and LLM-based development workflows introduce a new provenance question:
Who or what produced this code, what changed it, and what validation occurred before it entered the software supply chain?
Potential assurance issues include:
Incorrect implementation
Hallucinated APIs
Outdated implementation patterns
Insecure configurations
Duplicated code
Weak or misleading tests
Hidden dependencies
Licensing uncertainty
Missing business context
Architecture inconsistency
Inaccurate generated comments
These are not arguments that AI-generated code is inherently unsafe. They are arguments for making the development process more observable.
GitHub’s own guidance says generated code should be reviewed and tested rather than treated as a replacement for human programming judgment.
The assurance relationship can therefore be expressed as:
AI-generated code
↓
AI code audit
↓
Code intelligence
↓
Software assurance
↓
Governance
↓
Business accountability
For executives, the evidence request changes from “Did developers review the code?” to a more complete set of questions:
Which changes were AI-assisted?
Which changes were human-reviewed?
What automated analysis was performed?
Were generated dependencies identified?
Were tests generated, modified, or independently validated?
Was the code consistent with architecture standards?
Can the organization reconstruct the change history?
Emerging coding-agent workflows are already combining agent-created changes with automated security validation, illustrating how AI development is becoming part of the software assurance pipeline rather than a separate phenomenon.
AI changes the assurance requirement from simply reviewing code to establishing evidence about how code was generated, modified, validated, and approved.
How to Understand Third-Party Software Risk Without Reading the Code
Executives do not need to read thousands of lines of source code to understand software risk. They need structured evidence about what software exists, what it depends upon, how it was produced, who owns it, how it performs against required controls, and what unresolved conditions could affect the business.
The Six-Stage Software Risk Intelligence Framework
DISCOVER
↓
MAP
↓
ANALYZE
↓
VALIDATE
↓
GOVERN
↓
MONITOR
↺
1. Discover
Establish the software estate.
Identify:
The first question is not “Is it secure?”
It is “What exactly are we responsible for?”
2. Map
Create an inventory and dependency graph.
The graph should distinguish:
This matters because a business application may rely on components that are not visible in its immediate dependency declaration.
CISA describes an SBOM as an important building block for software supply-chain risk management, while also emphasizing the need to consume and maintain dependency information throughout the lifecycle.
3. Analyze
Assess evidence across:
Security vulnerabilities
Architecture
Technical debt
Code quality
Secrets
Licensing
Provenance
Maintainability
Testing
Documentation
Observability
Ownership
AI-assisted changes
This is where code intelligence becomes useful. A platform such as The Code Registry can represent the type of capability enterprises may use to connect source-level evidence with broader software-governance questions without requiring every executive to inspect source code manually.
4. Validate
Technical findings must be compared against organizational requirements.
For example:
Finding:
Legacy authentication framework
Technical interpretation:
Unsupported or difficult-to-modernize component
Business validation:
Does the application need to support a new identity standard?
Decision:
Modernization required before strategic deployment
Validation should consider:
Business requirements
Architecture standards
Security policies
Compliance obligations
Operational requirements
Ownership expectations
5. Govern
Governance turns evidence into decisions.
Controls may include:
Risk thresholds
Approval gates
Repository policies
Dependency policies
Code ownership
Release governance
Security controls
Exception management
A finding becomes useful when the organization knows who decides whether the risk is acceptable.
6. Monitor
Software changes continuously.
Monitor:
Dependencies
Vulnerabilities
Provenance
Architecture drift
Technical debt
Ownership
AI-assisted changes
Compliance posture
CNCF guidance similarly emphasizes supply-chain visibility, dependency tracking, build metadata, provenance, and continuous monitoring rather than treating security as a single point-in-time activity.
Software risk assessment should operate as a lifecycle of discovery, evidence, decision, control, and monitoring—not as a one-time scan.
What Should a Software Due Diligence Review Examine?
Software due diligence establishes evidence about the technical condition and future viability of a software asset. A serious review examines code, architecture, security, dependencies, provenance, licensing, maintainability, testing, documentation, observability, ownership, governance, AI-generated code, technical debt, and software inventory.
A useful review connects each category to both evidence and consequence.
| Area | Evidence to examine | Risk if ignored | Potential business consequence |
|---|
| Code quality | Static analysis, complexity, duplication | Fragile implementation | Higher change cost |
| Architecture | Dependency and component relationships | Excessive coupling | Integration and modernization risk |
| Security | Vulnerability and code-security findings | Exploitable weakness | Incident exposure |
| Dependencies | Direct/transitive inventory | Supply-chain exposure | Remediation or outage risk |
| Secrets | Secret scanning and configuration review | Credential exposure | Security incident |
| Provenance | Commit, build and artifact lineage | Assurance gap | Audit and trust uncertainty |
| Licensing | Component/license inventory | Compliance conflict | Legal or commercialization constraint |
| Maintainability | Complexity, age, ownership, documentation | Support difficulty | Rising operating cost |
| Testing | Unit, integration, security and deployment tests | Regression uncertainty | Release instability |
| Documentation | Architecture and operational records | Knowledge concentration | Transition risk |
| Observability | Logs, metrics, traces, alerts | Low operational visibility | Longer diagnosis |
| Compliance | Applicable controls and evidence | Control failure | Regulatory or contractual exposure |
| AI-generated code | AI-assisted changes and validation | Assurance uncertainty | Review and governance gaps |
| Technical debt | Structural and maintenance indicators | Deferred modernization | Future investment burden |
| Ownership | Teams, repositories, responsibilities | Accountability gap | Slow remediation |
| Repository governance | Branch controls, approvals, access | Unauthorized or weakly controlled change | Integrity risk |
| Architecture drift | Difference between intended and actual architecture | Loss of design integrity | Growing complexity |
| Software inventory | Complete asset and component register | Unknown exposure | Incomplete risk decisions |
The important principle is that due diligence should not produce a collection of disconnected technical findings.
It should produce an explanation of condition, evidence, uncertainty, consequence, and required action.
That distinction is particularly important in acquisitions. A codebase with substantial technical debt may still be strategically valuable. The question is whether the debt is understood, priced appropriately, and compatible with the acquiring organization’s investment plan.
Software due diligence is the process of converting technical evidence into a defensible assessment of an asset’s current condition and future obligations.
The Software Risk Evidence Chain
The Software Risk Evidence Chain connects technical observations to business consequences. It prevents executives from treating individual findings—such as a dependency vulnerability or architecture warning—as isolated facts and instead asks how code, dependencies, provenance, architecture, security, quality, ownership, and governance interact to create enterprise risk.
The model is:
CODE
↓
DEPENDENCIES
↓
PROVENANCE
↓
ARCHITECTURE
↓
SECURITY
↓
QUALITY
↓
OWNERSHIP
↓
GOVERNANCE
↓
BUSINESS RISK
A practical example:
Unknown dependency
↓
Unclear maintainer
↓
Delayed security patch
↓
Vulnerable production component
↓
Operational exposure
↓
Business continuity risk
The chain can work in the other direction as well.
Suppose an acquisition target has a highly coupled architecture.
The technical evidence may show many components depending directly on one another. That creates change risk. If integration with the acquiring company’s platform requires modifications across those components, the integration program may become slower and more expensive.
The board does not need to understand every dependency edge.
It needs to understand:
Architecture coupling
→ change complexity
→ integration effort
→ investment requirement
→ acquisition economics
Mermaid representation:
flowchart LR
A[Code] --> B[Dependencies]
B --> C[Provenance]
C --> D[Architecture]
D --> E[Security]
E --> F[Quality]
F --> G[Ownership]
G --> H[Governance]
H --> I[Business Risk]
The chain also creates a useful executive discipline: every material technical finding should answer three questions.
What evidence supports the finding?
What uncertainty remains?
What business decision does the finding affect?
This is why code intelligence is increasingly relevant to enterprise governance. The goal is not simply to produce more technical findings. It is to connect technical evidence into an intelligible model of software condition.
The Code Registry is an example of the type of capability that can help organizations establish this evidence layer across code intelligence, software due diligence, AI code risk, and governance.
Technical evidence becomes executive risk information only when its relationships to ownership, governance, and business consequences are understood.
AI Code Audits vs Traditional Code Reviews
Traditional code review is usually focused on whether a proposed change is correct, understandable, and consistent with engineering standards. An AI code audit extends the evidence model across the broader codebase, dependencies, provenance, architecture, technical debt, and AI-assisted changes. It complements rather than replaces expert human review.
| Dimension | Traditional Code Review | AI Code Audit |
|---|
| Primary objective | Code correctness | Correctness + risk evidence |
| Scope | Change set | Codebase and history |
| Reviewer | Human peer | Humans + automated intelligence |
| Provenance | Often implicit | Explicit |
| Dependencies | Often limited | Dependency graph |
| Architecture | Local context | System context |
| Security | Review + scanners | Broader risk analysis |
| AI-generated code | Usually invisible | Explicit assessment |
| Technical debt | Often incidental | Systematic analysis |
| Governance | Process-driven | Evidence-driven |
| Executive risk | Indirect | Explicitly mapped |
Automated code intelligence is particularly useful for scale.
A human reviewer may understand a pull request deeply but have limited ability to inspect every historical dependency, duplicated implementation, architecture relationship, or repository-level ownership issue.
Automation can surface those patterns. Humans remain necessary for context, prioritization, trade-offs, business requirements, and acceptance of residual risk.
The distinction is therefore:
Automation discovers evidence.
Experts interpret evidence.
Governance decides what evidence means for the enterprise.
AI code auditing should expand the evidence available to human reviewers and decision-makers, not eliminate human engineering judgment.
Software Supply Chain Risk: What Executives Need to Know
Software supply-chain risk concerns the integrity, security, transparency, and reliability of everything involved in producing and delivering software. Executives should understand SBOMs, provenance, dependency governance, build integrity, trusted repositories, and secure development practices as complementary evidence—not interchangeable controls.
An SBOM, or Software Bill of Materials, describes the software components contained in a product. CISA identifies SBOMs as a key building block for software supply-chain risk management.
But an SBOM is an inventory, not a complete assurance argument.
It can tell an organization what components are present without necessarily establishing:
Whether the artifact was built from trusted source
Whether the dependency was modified
Whether the build pipeline was compromised
Whether the component is actively maintained
Whether the architecture is appropriate
Whether the component is configured securely
Whether the organization can remediate it
SLSA addresses provenance: verifiable information about where, when, and how an artifact was produced.
NIST SSDF provides a broader secure-development framework, including practices around provenance and secure environments.
CISA’s current SBOM guidance also highlights software producer information and unknown provenance as relevant transparency considerations.
Executives should therefore expect suppliers to provide evidence such as:
Current SBOMs
Dependency inventories
Vulnerability-management processes
Software provenance
Build and release controls
Security-development practices
Incident-response processes
Ownership information
License information
Support lifecycles
The supply chain is broader than open-source packages. CNCF describes it as encompassing source code, build systems, third-party libraries, deployment infrastructure, and delivery repositories.
An SBOM answers “what is inside?” while provenance and governance help answer “where did it come from, how was it produced, and can we trust the evidence?”
Technical Debt and Architecture Risk Are Business Risks
Technical debt and architecture risk become business risks when structural weaknesses increase the cost, uncertainty, or time required to change, operate, secure, or integrate software. They can therefore affect acquisition valuation, modernization budgets, delivery capacity, operational resilience, and the long-term economics of a technology asset.
Important signals include:
Consider architecture drift.
The intended architecture may specify clear service boundaries. Over time, emergency fixes and undocumented dependencies can create direct calls between components that were supposed to remain independent.
The technical signal is architectural coupling.
The business implication may be:
Architecture drift
→ harder change
→ larger regression surface
→ slower releases
→ greater modernization cost
This is why technical debt belongs in software due diligence.
Debt is not automatically bad. Some debt represents deliberate trade-offs. The risk emerges when debt is undocumented, unmanaged, growing, or incompatible with the organization’s strategic direction.
A software asset with substantial debt can still be valuable. But its value should reflect the investment required to operate and modernize it.
Architecture quality and technical debt are indicators of the future cost and flexibility of a software asset, not merely measures of developer productivity.
Common Mistakes in Software Risk Assessment
Most software-risk mistakes are evidence mistakes. Organizations often rely on one signal—such as vulnerability counts, popularity, or an SBOM—and treat it as a complete assessment. The better approach is to identify what the evidence proves, what it does not prove, and what additional evidence is required.
| Misconception | Why it fails | Missing evidence | Better approach |
|---|
| “The software is widely used, so it must be safe.” | Popularity does not establish suitability for your environment. | Architecture, configuration, ownership | Assess against enterprise requirements. |
| “There are no critical vulnerabilities.” | Vulnerability scanning is not complete assurance. | Architecture, provenance, maintainability | Combine security and software-condition evidence. |
| “The SBOM tells us everything.” | An inventory does not prove build integrity or maintainability. | Provenance, ownership, architecture | Treat SBOM as one evidence layer. |
| “Open source requires no governance.” | Open source still creates dependency and licensing obligations. | Ownership, license, support | Apply dependency governance. |
| “The code works, so architecture is acceptable.” | Current functionality does not establish future changeability. | Architecture and debt | Assess maintainability and strategic fit. |
| “Ownership is obvious.” | Repositories and systems often outlive teams. | Explicit responsibility | Assign accountable owners. |
| “AI-generated code equals human-reviewed code.” | Generation and validation are different activities. | Review, testing, provenance | Require appropriate human validation. |
| “It was assessed once, so it remains safe.” | Dependencies, code, configuration, and ownership change. | Current-state evidence | Monitor continuously. |
| “Security scanning equals due diligence.” | Security is only one dimension of software condition. | Architecture, quality, licensing, governance | Conduct multidimensional assessment. |
A mature software-risk program manages evidence gaps as deliberately as it manages known technical defects.
Building an Enterprise Software Governance Model
Enterprise software governance connects engineering controls with organizational accountability. Secure SDLC practices, AI coding policies, repository controls, dependency governance, SBOMs, provenance, automated analysis, human approval, and continuous monitoring should work as one control system rather than as disconnected security tools.
The model can be understood as three layers:
DEVSECOPS
Secure delivery
↓
AI CODE AUDIT
Deeper code + AI-assisted risk analysis
↓
SOFTWARE GOVERNANCE
Enterprise control + accountability
Relevant controls include:
Secure SDLC
AI coding policies
Repository governance
Branch protection
Code ownership
Secrets management
Dependency governance
SBOM
SLSA
NIST SSDF
OWASP guidance
Policy as Code
Automated testing
Static analysis
Dynamic analysis
AI-assisted review
Human approval gates
Provenance controls
Continuous monitoring
NIST’s SSDF is particularly useful because it provides a common language that can be used not only by developers but also by software purchasers and consumers in acquisition and management activities.
CNCF guidance similarly emphasizes controls spanning source integrity, dependencies, testing, provenance, artifacts, and policy enforcement.
Governance turns technical findings into repeatable organizational behavior.
For example:
Dependency exceeds risk threshold
↓
Policy identifies violation
↓
Owner assigned
↓
Exception or remediation decision
↓
Approval recorded
↓
Risk monitored
The result is accountability rather than merely visibility.
Governance is the mechanism that turns software evidence into repeatable decisions, controls, ownership, and accountability.
From Periodic Code Review to Continuous Software Intelligence
Software assurance is moving from periodic inspection toward continuous visibility because software itself changes continuously. Dependencies update, repositories evolve, infrastructure changes, AI coding agents modify code, and build pipelines produce new artifacts. The objective is not continuous manual review; it is continuous collection and interpretation of relevant software evidence.
The progression is:
Periodic Code Review
↓
Continuous Code Intelligence
↓
Continuous Software Assurance
Capabilities emerging around this model include:
Autonomous coding agents
AI software assurance
Continuous AI code auditing
Software provenance
Governance automation
Code intelligence
AI-assisted DevSecOps
Internal developer platforms
Platform engineering
Policy as Code
Continuous software inventory
Automated technical-debt analysis
This does not mean every software asset requires the same level of control.
Risk-based governance remains essential.
A low-risk internal tool and a system supporting a critical business process should not necessarily have identical assurance requirements.
The important change is that organizations increasingly need machine-readable evidence that can be updated as software changes.
CISA notes that modern automated environments can change software composition frequently and that SBOM information must evolve accordingly. (CISA)
As software changes faster, continuous software intelligence becomes necessary to maintain an accurate picture of risk rather than relying exclusively on historical assessments.
Key Takeaways
Executives do not need to become software engineers to govern software risk. They need a structured evidence model that connects technical condition to business consequence. The most useful questions concern what software exists, what it depends on, where it came from, who owns it, how it is maintained, and whether its current condition matches business requirements.
Software risk is multidimensional. Vulnerability counts are only one part of the risk picture.
Provenance matters because evidence must itself be trustworthy. Organizations need confidence about where software and artifacts came from and how they were produced.
Dependencies create indirect risk. An application inherits exposure from components it relies upon, including transitive dependencies.
AI-generated code creates an additional assurance question. Organizations need evidence about generation, review, testing, and approval.
An SBOM is necessary evidence but not complete assurance. It identifies components; it does not by itself establish architectural, operational, or provenance trust.
Architecture and technical debt affect software economics. Structural weaknesses can increase modernization and integration costs.
Ownership is a risk control. An unresolved finding without an accountable owner is not effectively governed.
Governance converts technical evidence into decisions. Policies, thresholds, approvals, exceptions, and monitoring make risk manageable.
Software risk should be monitored continuously. The software estate changes through releases, dependencies, infrastructure, and AI-assisted development.
The most dangerous unknown is an evidence gap. If an organization cannot establish what it owns, how it was produced, or how it is maintained, its confidence in the software is necessarily limited.
Conclusion
Software should be evaluated as an enterprise asset and risk surface—not simply as source code or a list of dependencies. The right question is not only whether software contains known vulnerabilities, but whether the organization has sufficient evidence that it is secure, maintainable, governable, explainable, and fit for its intended purpose.
The progression is:
Software
↓
Code
↓
Dependencies
↓
Provenance
↓
Architecture
↓
Security
↓
Quality
↓
Ownership
↓
Governance
↓
Business Risk
This model changes the executive conversation.
Instead of asking:
“Does this software contain vulnerabilities?”
leaders can ask:
“What evidence do we have that this software is secure, maintainable, governable, explainable, and fit for its intended business purpose?”
That question is more difficult, but it is also more useful.
It applies to software an organization builds internally, purchases from vendors, inherits through acquisition, receives from outsourcing partners, or assembles from third-party components.
The Code Registry represents the type of code-intelligence and software-governance capability enterprises can use to establish this evidence across areas such as AI code risk, software due diligence, technical debt, software supply-chain intelligence, and executive software-risk reporting.
For organizations establishing this capability, useful next steps include requesting an AI Code Risk Assessment, evaluating software-governance maturity, conducting an enterprise software/code review, or exploring code intelligence for AI-assisted software development.
The central principle remains simple:
The most dangerous software risk is not necessarily the vulnerability an organization can see. It is the risk the organization lacks the evidence, provenance, intelligence, or governance capability to see.
FAQ
1. What is software risk?
Software risk is the possibility that software will fail to meet required security, operational, architectural, legal, financial, maintainability, or governance expectations. It includes known vulnerabilities but also risks from dependencies, provenance, technical debt, architecture, licensing, ownership, configuration, and insufficient evidence.
A complete software-risk assessment therefore examines both known defects and unknowns.
2. What is third-party software risk?
Third-party software risk is the exposure created when an organization depends on software it did not fully develop or control. It can involve open-source libraries, commercial components, SaaS integrations, outsourced code, external APIs, build tools, and transitive dependencies.
The risk includes security, availability, licensing, support, provenance, and remediation concerns.
3. How do you assess third-party software risk?
Assess third-party software by identifying the software and its dependencies, examining provenance and security, evaluating architecture and maintainability, verifying licensing and ownership, and comparing the evidence against business requirements.
An SBOM is useful for component inventory, while provenance and governance evidence provide additional assurance about how software was produced and maintained.
4. What should software due diligence examine?
Software due diligence should examine code quality, architecture, security, dependencies, secrets, provenance, licensing, maintainability, testing, documentation, observability, compliance, technical debt, AI-generated code, ownership, repository governance, architecture drift, and software inventory.
The objective is to establish the asset’s current condition, future obligations, and material uncertainties.
5. What is an AI code audit?
An AI code audit is an assessment of software using automated code intelligence and human analysis to identify security, quality, architecture, dependency, provenance, technical-debt, and governance risks, including risks associated with AI-assisted development.
It should augment human review rather than replace engineering judgment.
6. How should enterprises assess AI-generated code?
Enterprises should assess AI-generated code using the same engineering and security controls applied to other code, while adding evidence about how AI was used. Organizations should track relevant changes, require appropriate human review, test generated code, analyze dependencies, and apply repository and release governance.
GitHub recommends reviewing and testing AI-generated code rather than treating it as automatically correct.
7. What are the biggest risks of third-party dependencies?
Major risks include vulnerable or abandoned components, transitive dependencies, insecure or untrusted sources, licensing obligations, unavailable maintainers, compatibility problems, and difficulty responding to newly discovered issues.
Dependency governance reduces these risks by maintaining inventories, defining acceptable sources, tracking versions, monitoring vulnerabilities, and assigning ownership.
8. Is an SBOM enough to assess software supply-chain risk?
No. An SBOM provides an inventory of software components and is an important supply-chain evidence layer, but it does not independently establish build integrity, provenance, architecture quality, configuration security, maintainability, ownership, or operational suitability.
CISA describes SBOMs as a key building block rather than a complete software-risk model.
9. How does software provenance reduce risk?
Software provenance provides verifiable information about where, when, and how software was produced. It helps organizations trace artifacts to source and build processes and supports stronger confidence in software integrity.
SLSA uses provenance as a core mechanism for establishing verifiable supply-chain information.
10. How can enterprises continuously monitor software risk?
Enterprises can continuously monitor risk by maintaining software inventories, dependency graphs, SBOMs, vulnerability intelligence, provenance information, repository controls, architecture indicators, ownership records, technical-debt signals, and governance policies.
Automation should surface material changes while humans make risk-acceptance and business-priority decisions.
Glossary
AI-generated code: Source code produced or materially modified by an AI system, including LLM-based coding assistants, autonomous agents, or AI pair-programming tools.
AI Code Audit: A structured assessment using automated code intelligence and human expertise to identify security, quality, architecture, dependency, provenance, AI-development, and governance risks.
Code Intelligence: The analysis and contextual understanding of source code, dependencies, architecture, history, ownership, and related software evidence to support engineering and business decisions.
Third-Party Software Risk: Risk created by software components, services, libraries, or code supplied or controlled by external parties.
Software Due Diligence: A structured investigation of software condition, security, architecture, dependencies, ownership, maintainability, governance, and future obligations.
DevSecOps: A software-delivery approach integrating security practices throughout development, testing, deployment, and operations.
SBOM: Software Bill of Materials; an inventory describing software components and their relationships within a software product.
Software Provenance: Verifiable information describing the origin and production history of software or software artifacts.
SLSA: Supply-chain Levels for Software Artifacts, an industry framework for improving software supply-chain integrity and provenance.
NIST SSDF: NIST’s Secure Software Development Framework, a set of high-level secure-development practices designed to integrate security into software development lifecycles.
Technical Debt: Future cost or constraint created when software design, implementation, testing, or documentation choices make later maintenance or change more difficult.
Software Governance: Organizational policies, controls, accountability mechanisms, and decision processes used to manage software risk.
Software Supply Chain: The people, source code, dependencies, tools, build systems, infrastructure, artifacts, and delivery mechanisms involved in producing and distributing software.
Dependency Governance: Policies and controls governing which software dependencies may be used, how they are sourced, monitored, updated, and owned.
Architecture Drift: The divergence between intended system architecture and the architecture that exists after accumulated implementation changes.
Policy as Code: Encoding organizational or security policies in machine-readable form so they can be automatically evaluated and enforced.