For the past decade, DevSecOps answered a fundamental question: how do you build security into the software delivery lifecycle instead of bolting it on at the end? The answer proved correct, and the methodology was widely adopted. But the world has changed. AI systems entered production environments, regulatory frameworks (EU AI Act, DORA, NIS2) began imposing documentation and audit obligations, and software supply chains grew to a scale that no manual audit can handle. In response to these challenges, JFrog proposed a new working philosophy: DevGovOps.
Table of contents:
- Where Did DevGovOps Come From?
- How Does DevGovOps Differ from DevSecOps?
- Three Pillars of DevGovOps
- JFrog AppTrust – DevGovOps in Practice
- Regulatory Context: Why Now
- DevGovOps and AI: A New Dimension of Challenge
- From Theory to Implementation: First Steps
- Cultural Shift: Governance as a Service for Developers
- Conclusion
Where Did DevGovOps Come From?
DevSecOps solved the problem of security isolation from developers. Before its adoption, security testing was the domain of a separate team that reviewed finished code once a quarter. Integrating security into CI/CD pipelines radically accelerated vulnerability detection and reduced remediation costs. However, this model left a gap in risk and compliance management — processes that were still mostly handled manually, by a separate department, disconnected from the delivery pipeline.
Governance, Risk & Compliance (GRC) meant filling spreadsheets, running annual audits, and preparing documentation on demand. Meanwhile, software release velocity kept growing: instead of a few versions per year, teams now ship tens or hundreds of new versions per month. Traditional GRC simply couldn’t keep up.
JFrog defined DevGovOps as a framework that integrates governance, risk, and compliance directly into the software development lifecycle and security practices — so that the entire process is automated, verifiable, and continuous rather than episodic.
How Does DevGovOps Differ from DevSecOps?
DevSecOps focuses on detecting and remediating vulnerabilities: code scanning, software composition analysis (SCA), application security testing (SAST/DAST), secrets management. This remains critically important, but it stops at the question “is the software secure?”
DevGovOps goes further and asks: “Can we prove it — automatically, continuously, and in an auditable way?” It adds a layer of evidence, promotion policies, and control gates that transform scan results into verifiable attestations, which in turn form the basis for certifying every release.
| Dimension | DevSecOps | DevGovOps |
| Primary goal | Detect and remediate vulnerabilities | Proven, certified release compliance |
| Security evidence | Scanner reports | Automatic attestations tied to artifact versions |
| Audit process | Manual, periodic | Continuous, embedded in CI/CD pipeline |
| Accountability | Security team | Shared: dev, sec, GRC, CISO |
| Regulatory support | Indirect | Direct (EU AI Act, DORA, SBOM, NIS2) |
| Post-deployment monitoring | Optional | Built-in — new CVE alerts after release |
The difference is qualitative: DevSecOps protects, DevGovOps protects and proves that protection. In an era of regulation where software producers bear legal responsibility for the security of their products, this distinction becomes critical.
Three Pillars of DevGovOps
❶ Visibility at the Application Level, Not the Artifact Level
Traditional DevSecOps tools operate at the level of individual artifacts: container images, libraries, binaries. DevGovOps introduces the concept of an application entity — a logical unit grouping all related artifacts, their versions, business owners, velocity metrics (DORA), SLA commitments, and compliance history.
This means a CISO and a compliance manager see not raw scanner data, but the answer to a business question: “Does version 3.7.1 of our billing application meet all required policies and can we safely deploy it to production?” Business context replaces tool noise.
❷ Evidence-Based Control Gates
At the heart of DevGovOps are evidence-based control gates. Every stage of the software lifecycle — from code commit, through build, testing, artifact promotion, to deployment — can be conditioned on satisfying defined policies, the fulfillment of which must be confirmed by hard evidence.
Evidence is not a team’s claim that a scan was performed — it is a verifiable, digitally signed record of the result, automatically collected by the platform or provided by integrated partner tools. It may include a security scan result, a quality test report, confirmation of reviewer approval, artifact provenance verification (SLSA), or completeness of a Software Bill of Materials (SBOM).
If evidence is not provided or a policy is not met, the gate blocks promotion to the next stage — before the issue reaches the production environment. The action is analogous to a quality control gate on an assembly line: no component proceeds without the required certifications.
❸ Continuous Post-Deployment Monitoring
DevSecOps historically focused on the pre-deployment phase. DevGovOps extends protection to the time after release: a certified release is continuously monitored for new vulnerabilities (CVEs). When a new vulnerability affects a component included in an already-deployed application, the system immediately generates an alert, identifying exactly which versions and which environments are exposed.
This means the concept of a “Trusted Release” is not a permanent state granted once and for all, but a dynamic assessment updated in real time. A security certification expires automatically when a justified risk emerges.
JFrog AppTrust – DevGovOps in Practice
The DevGovOps philosophy found its practical embodiment in JFrog AppTrust, officially described by the vendor as a “DevGovOps solution.”
AppTrust functions as an application risk management layer embedded directly in the JFrog Platform ecosystem, which includes Artifactory (artifact management) and Xray (security and compliance analysis). It does not require replacing an existing tool stack — it integrates with it and adds the missing certification layer.
Key AppTrust capabilities include:
- Application entity — automatic assignment of every software asset to an application with a defined owner and business context;
- Evidence-based policy engine — defining rules enforced at every SDLC stage with automatic evidence collection;
- Trusted Release badge — visual confirmation that a version meets all defined security, quality, and compliance policies;
- Post-deployment monitoring — alerts on new CVEs affecting published versions with contextual vulnerability analysis;
- Audit trail — searchable activity log with the ability to trace an issue back to the originating code commit or dependency that introduced it;
In practice, before a software version reaches the production environment, it must pass through a sequence of defined gates. The “Code Quality” gate requires a unit test report above a set coverage threshold. The “Security Scan” gate requires no critical vulnerabilities, or their documented risk acceptance signed by the CISO. The “Change Management” gate requires an approved ticket in the ITSM system. Only when all gates are passed with supporting evidence does the artifact receive Trusted Release status and become eligible for production deployment.
Regulatory Context: Why Now
The full application deadline for the EU AI Act is August 2, 2026. DORA (Digital Operational Resilience Act) came into full force in the financial sector in January 2025. NIS2 imposes supply chain risk management obligations on hundreds of thousands of entities across Europe. For all these regulations, the common denominator is documented, verifiable compliance — not assurance of compliance.
In parallel, JFrog’s Software Supply Chain State of the Union 2026 report, based on data from over 1,500 professionals across 8 countries, confirms a growing gap between the pace of AI adoption and organizational readiness to govern it. Large language models, AI-assisted development tools (Copilot, Cursor), and AI agents are entering production environments faster than security teams can develop appropriate procedures.
This gap is the driving force behind DevGovOps: regulations demand evidence, AI multiplies the attack surface and the need for oversight, and classic GRC does not scale to the pace of modern software delivery. Governance automation becomes not an option, but a necessity.
DevGovOps and AI: A New Dimension of Challenge
Incorporating AI systems into software products adds an entirely new category of assets requiring governance. A language model is not a library: it has its own provenance (training data, producer, version), its own risk profile (bias, hallucinations, susceptibility to prompt injection attacks), and its own documentation requirements (AI Bill of Materials, model cards).
JFrog responded to this challenge by extending the platform with:
- JFrog AI Catalog — a central repository for managing AI models and their lifecycle, enabling provenance verification, vulnerability scanning, and access control;
- Agent Skills Registry — a registry of AI agent skills developed in partnership with NVIDIA, treating agent components as software artifacts subject to the same rigorous policies as production code;
- JFrog MCP Registry — management and security of Model Context Protocol (MCP) servers with automated policy enforcement.
In practice, an AI model entering the production pipeline must pass through the same AppTrust gates as any other component: provenance verification, vulnerability scan, data access policy, and security owner approval. Trust in software extends to trust in its AI components.
From Theory to Implementation: First Steps
Transitioning to DevGovOps does not require a one-time revolution. A practical implementation path covers four stages:
- Stage 1 – Visibility: Build an application registry with assigned owners and map all artifacts to application entities. Without knowing what you have, you cannot govern it..
- Stage 2 – Initial Policies: Define minimum policy sets for the most critical applications. Start from what already exists: results from existing scans become the first pieces of evidence. Don’t build gates from scratch — adapt what you have.
- Stage 3 – Evidence Automation: Integrate evidence collection into the CI/CD pipeline so it is fully automatic. Developers should not manually attach certificates — the platform does it automatically based on tool results in the pipeline.
- Stage 4 – Expansion and Maturation: Gradually extend coverage to more applications, add gates for AI components, broaden policy scope in line with regulatory requirements, and increase the maturity of the governance model.
Cultural Shift: Governance as a Service for Developers
Największym wyzwaniem wdrożenia DevGovOps nie jest technologia, lecz kultura. Historycznie zespoły GRC i deweloperzy działały w napięciu: pierwsi spowalniają, drudzy przyspieszają. DevGovOps proponuje zmianę perspektywy: zarządzanie ryzykiem przestaje być bramkarzem zwalniającym, a staje się usługą, która automatycznie potwierdza, że kod spełnia wymagania – umożliwiając szybsze, pewniejsze wdrożenia.
Deweloper nie wypełnia formularzy zgodności. Pisze kod, a platforma automatycznie zbiera dowody, weryfikuje polityki i sygnalizuje niezgodności na etapie, gdy koszt ich naprawy jest najniższy – przed przejściem do kolejnego etapu SDLC, nie podczas audytu rocznego. To przesunięcie odpowiedzialności i widoczności w lewo (ang. shift left), ale zastosowane nie tylko do bezpieczeństwa, lecz do całego obszaru zarządzania ryzykiem.
Organizacje, które przyjmą tę filozofię, zyskują podwójną przewagę konkurencyjną: szybsze, bardziej pewne wydania oprogramowania z jednej strony, oraz gotowość audytową i odporność regulacyjną z drugiej. W środowisku, gdzie jeden incydent bezpieczeństwa lub jedna grzywna regulacyjna może kosztować więcej niż wieloletnie inwestycje w bezpieczeństwo, to nie jest przewaga luksusowa – to warunek przetrwania.
Conclusion
DevGovOps is the natural evolution of DevSecOps adapted to the realities of 2026: complex software supply chains, AI systems in production, and regulatory requirements that demand verifiable evidence rather than declarations. It does not replace security — it extends it with a governance dimension, automating and embedding GRC into every stage of the delivery pipeline.
JFrog AppTrust is today the most mature commercial implementation of this philosophy, but the paradigm itself is broader: it is a change in how we think about software accountability. The question is no longer “did we scan this code?” but “can we prove it, and does that trust hold over time?”.
For organizations planning adoption, a useful starting point is a single question: how long would it take your team to deliver complete compliance documentation for your five most critical applications to an auditor? If the answer is “weeks” — DevGovOps just became your top priority.
