Methodology
You do CI.
You do CD.
Do you do CA?
Continuous Integration and Continuous Delivery transformed how teams ship software. But the pipeline has a blind spot. Here is what comes next.
The pipeline we built
Continuous Integration gave us confidence. Every commit triggers a build, tests run, regressions surface early. Continuous Delivery extended that confidence outward — code that passes CI can ship, automatically, reliably, at any time. Together, CI/CD became the backbone of modern software delivery. Teams that practice it ship faster, with fewer incidents, and with more trust in their own work.
But CI/CD is fundamentally a pipeline about correctness. Does the code compile? Do the tests pass? Is the artefact deployable? It says nothing about the supply chain those artefacts carry with them. And that supply chain — the hundreds of open source components, the transitive dependencies, the base images, the licences — is where a different class of risk lives entirely.
The blind spot
Most teams have added security scanning to their pipelines. A Grype step here, a Syft SBOM there. Licence checks, static analysis, dependency audits. The tools exist and many teams run them. But running a scan is not the same as analysing your supply chain over time.
When a scan runs in CI and the results vanish into a log or a flat JSON file in an artefact bucket, you have checked a box. You have not built a record. You cannot answer the question that actually matters during a security incident or a compliance audit:
"When did this component enter our supply chain, and what else came with it?"
That question requires history. It requires a build-by-build record of what your software contained, what vulnerabilities were present, which licences were in use, and what changed between each release. Without that record, every scan is a snapshot with no context. Useful, but incomplete.
Supply chain attacks changed the stakes
A trusted, widely-used compression library was compromised via a long-running social engineering attack on its maintainer. The malicious code was present for weeks before detection. Teams without build-by-build SBOM history had no way to determine exactly when the compromised version entered their supply chain — or what else changed at the same time.
The xz attack was not a zero-day in the traditional sense. It was a supply chain insertion — a deliberate, patient compromise of a component that teams trusted implicitly. The vulnerability wasn't in code you wrote. It arrived via a dependency update, in a package your build pulled automatically.
This is the class of threat that point-in-time scanning cannot adequately address. A scan tells you what is vulnerable today. Only a continuous historical record tells you when it became vulnerable, what builds were affected, and what the blast radius was. That is a fundamentally different capability, and it requires a different approach.
Continuous Analysis
Continuous Analysis is the practice of accumulating a structured, queryable, build-by-build record of your software's security and compliance posture — not as a series of disconnected scans, but as a living audit trail that grows with every release.
What CVEs are present in this build? Which appeared since the last build? Which were resolved?
What licences does this build carry? Are any in violation of policy? Did anything change?
What components entered or left the supply chain? What does the SBOM look like over time?
Crucially, CA does not replace the tools you already run. Grype, Syft, Grant, Bandit, OWASP ZAP — these are excellent tools. CA is the layer that sits above them, receiving their output from your existing CI pipeline and transforming a stream of scan results into an auditable, comparable, historically coherent record.
Bring your own tools. CA aggregates their output — it does not compete with them.
Your pipeline already produces this data. CA gives it somewhere meaningful to go.
Why now
Tools for scanning these things have matured rapidly. These are production-grade, widely adopted tools that teams are already running in CI. But the ecosystem has not yet produced a standard answer for what to do with their output.
Teams store scan results as CI artefacts. In S3 buckets. In log aggregators never designed for structured security data. The data exists, but it is not queryable, not comparable across builds, not presentable to an auditor in any meaningful way.
SOC2, ISO 27001, and emerging supply chain regulations are increasingly asking not just "do you scan?" but "show me the evidence." A flat JSON file in a bucket is not evidence in the way an auditor means it. A build-by-build audit trail, with diffs, with policy evaluation, with historical trend data — that is.
The tools to practice CA are already in your pipeline. The methodology to make sense of their output is what has been missing. Until now.
What CA looks like in practice
Implementing CA is intentionally simple. Your CI pipeline already runs tools like Syft and Grype. You add a POST step at the end of your security stage. The scan results go to sit-rep. That is the entire integration.
From that point, every build contributes to a historical record. You can see your vulnerability profile build-by-build. You can see when a new component entered your SBOM. You can see which builds had licence violations and whether they were resolved. When an incident occurs — or when an auditor asks — the record is there.
CA is infrastructure you set up once. It runs alongside your existing tooling without displacing it. The discipline it enables — knowing the provenance and security posture of your software at every point in its history — is what separates teams that are genuinely secure from teams that merely run security tools.
The question worth asking
CI asked: does the code integrate cleanly?
CD asked: can we ship it reliably?
CA asks: do we understand what we are shipping, and can we prove it?
These are not competing questions. They are sequential ones. A mature engineering organisation answers all three. The first two are well-solved. The third is the frontier — and the teams that get there first will have a fundamentally different relationship with supply chain risk than those who don't.
You do CI. You do CD. The question is whether you do CA.
Start your audit trail today
sit-rep receives scan results from your existing CI pipeline and builds the historical record your supply chain analysis demands.
Get started free Read the docs