Contributed by Tracy Ragan, DeployHub
How Ortelius Brings SBOM Intelligence and Deployment Awareness to the Final Mile of DevSecOps
For over a decade, Jenkins has been the backbone of Continuous Integration and continuous Delivery for millions of developers worldwide. It has shaped how teams automate builds, orchestrate pipelines, and accelerate delivery. But even with strong CI/CD practices, the industry faces a reality that Jenkins alone cannot solve: vulnerabilities donât stop appearing once code is shipped.
In fact, the most dangerous risks emerge after deployment, precisely when systems are live, supporting real users, and running on distributed infrastructure. This is where traditional DevSecOps practices stop short, and where a new defensive discipline must take over: post-deployment vulnerability detection and rapid remediation.
The Security Gap in CI/CD Pipelines
Jenkins excels at automation before deployment, building, testing, scanning, packaging, and releasing software. Pre-deployment security tools such as SCA and SAST integrate directly into the pipeline, helping developers catch issues early with our âshift-left,â offensive, commitment.Â
But the threat landscape has shifted right and needs defensive measures:
- New CVEs are published every day
- Open source packages become vulnerable long after release
- Attackers exploit known weaknesses in production faster than organizations can patch
- Distributed, cloud-native environments make it harder to know exactly what is running where
By the time a vulnerability is announced, the code is already deployed. Jenkins pipelines have long finished their job, and the software continues running, often silently exposed.
This is the âlast mileâ of DevSecOps where most teams struggle. They know what they built but not what is actually running. They know a new vulnerability exists, but not which environments it affects. And they know it must be remediated quickly, yet lack a clear path to resolution.
Introducing Ortelius: Post-Deployment Intelligence for Jenkins Users
Ortelius, a sandbox project under the Continuous Delivery Foundation, was created to solve this last-mile challenge. It provides a standardized, open-source method for tracking what has been deployed, where, and with which dependent open-source packages.
Ortelius creates a deployment digital twin, a living model of every application version across clusters and environments. By mapping SBOM metadata to real deployments, Ortelius gives teams the one capability CI/CD pipelines cannot deliver on their own:
- Real-time insight into how newly discovered vulnerabilities impact running systems.
For Jenkins users, this shifts security thinking from a pre-deployment exercise to a continuous defensive posture.
Why the Jenkins Community Should Care
1. Vulnerabilities evolve after your pipelines finish
A package that was safe at build time may become high-risk days later. Without post-deployment detection, teams are flying blind.
2. SBOMs only become powerful when tied to deployments
Jenkins can generate SBOMs. Ortelius consumes the SBOM to show where those components ended up, and alerts you when they become dangerous.
3. Faster MTTR (Mean Time to Remediation) protects production
Jenkins excels at automation. Ortelius adds the intelligence needed to trigger targeted remediation pipelines instead of broad, time-consuming patch cycles.
4. Cleaner signal, less noise
Ortelius eliminates false alarms by connecting CVEs to the specific versions actually running in production. not every possible version that ever passed through the pipeline.
5. Open source, community-driven, and built to complement Jenkins
Because Ortelius is open source and part of the CDF ecosystem, it integrates naturally into Jenkins-based DevSecOps workflows.
A New Architecture for the CDF Community: The Deployment Digital Twin
Ortelius introduces a concept that is rapidly becoming essential to large-scale DevSecOps: the deployment digital twin.
This model continuously maps:
- Component versions
- Open source libraries
- SBOM details
- Deployment locations (clusters, namespaces, environments)
With this real-time knowledge, newly published vulnerabilities can be traced instantly to affected applications, something CI pipelines alone cannot do.
For Jenkins users, a digital twin becomes the authoritative record of “whatâs really running,” allowing security teams and developers to respond with surgical precision.
Post-Deployment Remediation: The Missing Step in Secure Delivery
Currently, the Ortelius community is working on auto-remediation once a new vulnerability is identified. In this step, Jenkins re-enters the picture:
Ortelius gives Jenkins pipelines actionable intelligence, enabling them to:
- Automatically generate targeted remediation branches
- Rebuild affected components with secure package versions
- Trigger re-tests and approvals
- Roll out patched versions across environments
- Create auditable compliance records
By connecting vulnerability impact â code change â rebuild â redeploy, Jenkins becomes an integral component of a trusted, closed-loop remediation workflow.
Why This Matters Now
The software supply chain is increasingly weaponized. Attackers move faster than traditional patch cycles. Developers face alert fatigue. Platform teams must protect distributed, cloud-native workloads running across hybrid environments.
The CDF community is uniquely positioned to champion a new model of security, one that extends beyond the build pipeline into real-time production awareness.
Post-deployment detection and remediation is no longer optional. It is the final mile of continuous delivery. And Ortelius is giving Jenkins users a powerful, open source way to close the gap, including:Â
| Capability Area | Jenkins | Jenkins with Ortelius |
|---|---|---|
| Security Focus | Pre-deployment, offensive security (SAST, SCA, scans during build) | Continuous, defensive security extending into post-deployment |
| Vulnerability Visibility After Release | No native visibility once pipelines complete | Real-time visibility into newly disclosed CVEs affecting running systems |
| Handling New CVEs | CVEs discovered after deployment require manual investigation | CVEs are automatically correlated to deployed versions via SBOM mapping |
| SBOM Usage | SBOMs may be generated but remain static artifacts | SBOMs are actively consumed and tied to live deployments |
| Knowledge of Whatâs Running | Knows what was built, not what is currently running | An authoritative view of what is actually running across environments |
| Deployment Awareness | Limited to pipeline execution history | Deployment digital twin tracks versions, locations, and dependencies |
| Signal vs. Noise | Broad alerts across all historical builds and versions | Precise alerts limited to vulnerable components actually in production |
| Mean Time to Remediation (MTTR) | Slow, manual triage and broad patch cycles | Faster MTTR through targeted, intelligence-driven remediation |
| Threat Landscape Analysis | Largely manual and error-prone | Automatic threat landscape identification across clusters and environments |
| Compliance & Audit Readiness | Fragmented evidence across tools | Auditable chain: vulnerability â fix â rebuild â redeploy |
| Architecture Model | Pipeline-centric | Pipeline + deployment digital twin |
| Role of Jenkins | Ends at delivery | Becomes part of a closed-loop remediation system |
Join the Movement: Help Build the Future of Defensive DevSecOps
Ortelius is a community-driven project, and its roadmap is shaped by practitioners who understand the challenges of modern software delivery. If you are a Jenkins user, DevSecOps engineer, or platform leader interested in strengthening post-deployment security, we invite you to get involved.
Join the Ortelius Open Source Project at Ortelius and bring your expertise to the community, shaping the future of post-deployment vulnerability defense.
Together, we can extend the principles of continuous delivery into continuous protectionâand build a safer, more resilient open source ecosystem for everyone.