As Mike Tyson said, “Everyone has a plan until they get hit” and software is no different changes happen after it passes a security review. Teams update libraries, adjust permissions, and change network configurations. Each change can affect the security posture of the running application, even when the application code stays the same.
Frontier AI accelerates both sides of fight. It can help defenders analyze code and investigate weaknesses, while giving attackers more capable ways to examine exposed systems and exploit vulnerabilities. For CISOs, this makes the connection between development, security testing, and operations especially important.
Continuous software assurance keeps those activities connected and automated. This post will discuss the evidence teams should retain, the changes that should trigger a fresh check, and a practical way to start with one application.
What continuous software assurance means
Software assurance is the evidence that gives an organization confidence that its software will behave as intended and that security risks are being managed. That evidence comes from design decisions, code review, testing, dependency analysis, configuration checks, and observation of running software.
A periodic approach collects this evidence at scheduled checkpoints. Continuous assurance keeps the evidence connected to the changes that could make it stale.
A code change should trigger relevant tests. A new supplier advisory should prompt a check for affected components. A permission change should trigger a review of what that identity can now access. Findings from an incident or red-team exercise should become engineering work with a named owner.
Continuous does not mean running every test every minute. It means selecting checks and review intervals based on risk and reassessing when a meaningful change calls an earlier conclusion into question.
Integrate security checks into delivery
AI-assisted development puts software assurance directly in front of engineering and security leaders. Teams can generate code quickly, but they still need to understand what it does, which dependencies it introduces, and how it behaves when something goes wrong.
Apply the same standards to AI-assisted code as any other contribution: assign an accountable owner, review and test the code, and evaluate its dependencies and required permissions. Plausible code and a confident explanation are not evidence that it is safe to deploy.
Build routine assurance into the delivery workflow. Automate code, dependency, container, and infrastructure-as-code checks where appropriate, and use policy-as-code to enforce requirements consistently. Reserve expert review for decisions requiring context and judgment.
Define what happens when a check fails. Which findings block a release? Who can approve an exception, and when does it expire? Teams can move faster when these decisions are established before a release is waiting.
Connect dependency records to deployed software to exploitability
Imagine a supplier discloses a vulnerability in a widely used library. The first question is simple: Do we use it? The answer can be surprisingly difficult when application inventories, build records, and production deployments do not align.
A current software bill of materials (SBOM) is a useful starting point because it identifies the components included in a release. But the real value comes from connecting that information to what is deployed and to the service that owns it. Knowing that a vulnerable library exists somewhere in the environment is not enough; security teams need to know which application is running it, where it is deployed, and who is responsible for it.
From there, the question becomes whether the vulnerability is exploitable in that environment. An SBOM cannot answer whether a vulnerable function is reachable or what impact an exploit could have. That requires application and operational context, including exposed interfaces, identity permissions, sensitive data, runtime configuration, and the dependencies involved in critical transactions.
Suppliers should be part of the same process. Organizations should understand how suppliers identify affected components, assess exploitability, notify customers, deliver fixes, and support incident response. A completed security questionnaire provides useful baseline information, but when a new vulnerability emerges, teams need a concrete answer about whether they are exposed today and what they should do next.
Example: A vulnerability in a deployed dependency
Suppose a new advisory affects a library used by a customer-facing application. A useful assurance workflow should allow the service owner to move from the advisory to a verified response:
- Confirm exposure. Verify that the affected version is present in the deployed release by correlating the SBOM with build and deployment records.
- Assess exploitability and impact. Determine whether the vulnerable functionality is reachable in the application and what interfaces, permissions, business data, or transactions could be affected.
- Correlate supplier guidance, when applicable. Capture the supplier’s assessment, affected versions, available fixes or mitigations, and relevant incident-response guidance.
- Validate the remediation. Test the update or mitigation against representative application behavior, including performance and failure scenarios.
- Deploy and verify. Release the change through the established change process, confirm the remediation in the deployed environment, and update the dependency record and relevant tests.
Keep the evidence connected to the work item. A ticket marked complete should point to the deployed version, validation results, and any remaining exceptions or compensating controls. This gives the next analyst a reliable starting point and creates a traceable record of the assurance decision.
Validate controls in the running environment
Production changes may undermine a sound design. An exception becomes permanent. A temporary account stays active. A network rule is widened for troubleshooting and never restored. None of these requires a new application release.
Continuous assurance connects engineering evidence with operational signals. Configuration monitoring, identity reviews, attack-path analysis, and control testing help teams check whether the protections they rely on still work together.
Penetration tests and red-team exercises remain valuable. Use their findings to improve the checks that run between exercises. If a test reveals a path from a low-privilege account to sensitive data, close it, verify the change, and create a way to detect that condition if it returns.
Cloud services do not remove this work. The exact division varies by service, but customers still need to understand the applications, permissions, integrations, and configurations they manage. Include those responsibilities in the assurance process, alongside the protections operated by the provider.
My article How to Test 3rd Party Agents and Security Agents for Compatibility on Exadata provides an example of workload-based validation: compare representative behavior before and after a security change. The same testing principle applies here. Check both the intended protection and the application’s ability to perform its business function.
For an example of repeatable configuration checks, check out Stop Treating CIS Compliance as a Point-in-Time Exercise by Marcus D’Andrea and I. This illustrates one part of assurance: regularly collecting configuration evidence. Those results still need to be assessed alongside application testing, dependency information, and operational context.
New evidence should lead to an owned decision, a verified change, and better checks for the next release.
Use AI to support analysis and validation
AI can assist analysts connect findings that would otherwise remain scattered across different tools. An LLM could compare a supplier advisory with an SBOM, identify potentially affected services, and highlight configuration or access conditions that warrant investigation.
This evidence will be provided to an analyst to inspect: the affected component, suspected attack path, assumptions, and tests needed to validate the risk. Treat the model’s output as an opinion, not a decision, validate it before acting. Production changes and risk acceptance should remain clearly defined with human decision makers.
Oracle’s published approach to vulnerability detection and response illustrates this direction: AI-assisted security testing and code analysis can help identify issues earlier but supported software and timely updates remain essential. The goal is not just better analysis, but connecting that analysis to actions that reduce exposure.
Getting started with one application
Choose one business application and walk its latest release from design through production with engineering, security, and operations. Use these questions to guide the process:
- Can we connect the running version to its code, dependencies, tests, and release decision?
- What changes should trigger a new exposure assessment?
- Do failed checks and exceptions have clear owners and review dates?
- Can we demonstrate that the last security fix reduced the intended risk?
Prioritize the gaps. Measure how quickly new advisories can be mapped to affected services, how much of the environment has current assurance evidence, and how long material findings remain unresolved. Keep vulnerability counts as an operational metric but provide enough context to explain business impact.
The goal is to make secure delivery repeatable without adding unnecessary meetings or manual handoffs. Agree on the evidence to retain, the changes that require reassessment, and who owns remediation. Repeat the process as the application changes, then extend it to the next critical service.