From Gap Analysis to Continuous Compliance: azuma nori in the CI/CD Pipeline
In many digital health teams, compliance is an event rather than a process: once a year, shortly before an audit or certification, someone checks where things stand. Every line of code written between two such deadlines goes unassessed until the next one – and the gaps discovered then are expensive to fix.
azuma nori supports both modes of operation: the classic gap analysis as a snapshot, and headless operation, which lets you automate the check inside your CI/CD pipeline. This article shows how to move from point-in-time to continuous compliance.
The gap analysis: compliance as a snapshot
The obvious starting point is a gap analysis: an inventory that shows where your codebase stands against a regulation and where the gaps are. That is valuable for clearly defined occasions:
- ahead of a certification or an audit, to know the current state;
- when taking over or performing due diligence on someone else's codebase;
- as a periodic health check, quarterly for example.
The gap analysis answers the question "where do we stand right now?" – reliably, repeatably, and without anyone having to hold the regulation up against the code by hand. For many teams, that alone is a major step up from a status quo of spreadsheets and gut feeling.
Its drawback is the same as with any snapshot: it ages. Between two analyses, the codebase can change considerably, and new gaps stay undetected until the next review date comes around.
Continuous compliance: checking inside the pipeline
The second mode closes exactly that gap. The nori execution engine is built as a fully headless, automation-ready process – meaning it can run unattended in a CI/CD pipeline, alongside tests, build, and deployment. Today, nori ships primarily via the Standalone Client; dedicated, official pipeline integrations for GitHub Actions, GitLab CI, and Azure DevOps have been announced and are part of the roadmap. The building blocks required for unattended operation are already in place.
This applies a proven principle from security to the regulatory domain: shift-left. Instead of finding problems late and expensively at the end, they surface early – where they are cheapest to fix, namely right where they originate in the development process.
Where the check runs as part of the automated flow, compliance turns from an annual event into a continuous state:
- Every change is assessed, not just the state on audit day.
- Regressions show up immediately instead of going unnoticed for months.
- Audit effort drops, because the evidence isn't reconstructed on the deadline but produced continuously along the way.
- Developers get feedback in the tool they already use – in the pipeline, not in a separate compliance process.
Technically, this works through the mechanics CI/CD systems already understand: the run emits structured logs (JSON) and signals its result via standard exit codes – 0 on a successful run, a non-zero value on configuration or runtime errors, or on a failed step. The build server uses that exit code to pass or fail the pipeline stage – which turns the compliance check from a mere report into a real gate. Secrets such as the API key are injected via environment variables rather than stored in the repository.
One tool, two speeds
The practical value lies in both modes using the same tool. Teams don't have to choose between a "thorough one-off analysis" and "automated continuous checking" – they can start with one and grow into the other:
- Start with a gap analysis – understand the current state without touching the pipeline.
- Repeat periodically – run the analysis on a fixed cadence.
- Integrate into CI/CD – automate the check headless via exit codes, once the team is ready.
That way, continuous compliance can be introduced step by step instead of being set up as a large migration project. It lowers the barrier to entry – especially for smaller digital health teams that can't or don't want to overhaul their entire pipeline right away.
Why this matters for regulated codebases
Regulations such as BSI TR-03161, the EU Cyber Resilience Act, and the EU AI Act don't just require one-time conformity, but security across the entire product lifecycle – including ongoing vulnerability management and documented processes. A continuous, automated check fits that expectation structurally better than an annual snapshot. Pulling compliance into the pipeline satisfies the "across the lifecycle" intent of such requirements almost as a side effect, rather than as a separate heavy lift.
Frequently asked questions
Can I use nori for a one-off analysis only?
Yes. The gap analysis works as a standalone snapshot – without you having to change anything in your pipeline.
How is nori integrated into a CI/CD pipeline?
Through the execution engine's headless mode: it runs unattended, emits JSON logs, and signals its result via standard exit codes that the build server evaluates as a gate. Today, the Standalone Client is the primary route; dedicated integrations for GitHub Actions, GitLab CI, and Azure DevOps are on the roadmap. You'll find the current status in the azuma nori technical documentation.
Does my code leave the company in the process?
No. nori runs locally; the source code never leaves the device. Details in the article "Compliance Analysis Without Code Upload".
Which regulations does the check cover?
nori covers several regulations – including BSI TR-03161 (parts 1–3) and BSI TR-02102 (parts 1–2) generally available, the EU CRA in beta, plus BSI TR-03107 and the EU AI Act in development. The current status is available on the product page.
Want to turn compliance from an annual event into a continuous state? Sign up for the free trial (three selected controls included) or get in touch.
As of: August 2026. Please verify the feature set, integration options, and covered regulations for azuma nori on the product page before implementation.