Picture an auditor asking: “How can you prove that version 4.2.1 of your payment application passed all required security checks before it went to production?” In many organizations, the answer is something like: “We have that in a spreadsheet… somewhere.” Or: “We can ask the DevOps team, they should remember.” This is not an exaggeration — it is the daily reality for hundreds of companies that treat regulatory compliance as a separate, manual process tacked onto the end of the delivery lifecycle.
JFrog AppTrust changes that answer to: “Every artifact promotion through each lifecycle stage is confirmed by a cryptographically signed piece of evidence, collected automatically by the platform. The complete audit trail is available instantly.” That is the difference between a promise and a proof. And that difference is exactly what AppTrust is built on. investors.jfrog
Spis treści:
- The Problem AppTrust Solves
- What Is AppTrust? The Conceptual Architecture
- Step by Step: Building a Trusted Release in AppTrust
- Integrations and Partner Ecosystem
- Use Cases: Who Uses AppTrust and How
- Benefits by Role
- Measuring Success: Built-In Analytics
- Getting Started: A Practical Adoption Path
- The Shift That Matters
The Problem AppTrust Solves
Before AppTrust, the typical compliance landscape in a mid-to-large software organization looked like this: several security scanners (SAST, DAST, SCA), a vulnerability management tool, an ITSM system for change approvals, and a GRC team operating on spreadsheets — asking developers to email screenshots as evidence of completed tests once a quarter.
This created a set of chronic, interconnected problems. Security teams were drowning in alerts with no business context — they had no way of knowing whether a vulnerability affected an internal tool or a customer-facing payment system. Development teams wasted time tracing component ownership and figuring out who was responsible for fixing which issue. GRC teams conducted post-release audits, verifying activities that had already happened, with no ability to influence the process. And nobody had a unified, coherent view of any single application.
New regulations no longer accept “we have it in a spreadsheet” as an answer. The EU AI Act, with a full compliance deadline of August 2026, DORA in force for the financial sector since January 2025, and NIS2 — all demand verifiable, documented evidence that security processes were carried out in a systematic and repeatable way.
What Is AppTrust? The Conceptual Architecture
JFrog AppTrust is an Application Risk Governance solution built natively into the JFrog Platform ecosystem. It is not another scanner or another alert aggregator — it is a governance layer that adds business context, evidence-based policies, and release certification to an existing tool stack.
The architecture rests on four main components:
❶ The Application Entity
At the center of AppTrust is the application entity — a higher-level abstraction that groups all related artifacts (container images, packages, binaries, libraries) into a single business unit with clearly defined owners, maturity levels, and organizational context. Instead of managing thousands of artifacts separately, teams manage dozens or hundreds of applications with full visibility into their composition.
The application entity automatically assigns software assets to the correct application, tracks DORA metrics (deployment frequency, mean time to recovery, change failure rate), monitors SLA commitments, and maintains a full version registry with the history of every action — who promoted what, and when.
❷ Evidence-Based Policies and Control Gates
Every lifecycle stage (development, QA, staging, production) can be equipped with entry and exit gates. A gate is a set of policies that an application version must satisfy before it can advance. Policies can cover security, quality, compliance, or operational requirements.
Critically, satisfying a policy requires evidence — a verifiable, cryptographically signed record of the outcome, not a declaration. Evidence can be generated automatically by the JFrog Platform (for example, an Xray scan result), provided by integrated partner tools (GitHub, ServiceNow, SonarQube, and others), or uploaded manually by the team in cases requiring human judgment.
If evidence is missing or a policy is not met, the gate responds according to its configuration: it can block promotion entirely or allow the version through with a warning and a generated alert. This flexibility lets organizations calibrate the rigor of controls to the stage and criticality of the application.
❸ The Trusted Release Badge
When an application version successfully passes all defined gates with supporting evidence, it receives Trusted Release status — a digital seal confirming it met all required security, quality, and compliance policies at the time of deployment.
The badge is immutable and tied to a specific artifact version — it cannot be transferred to another version or modified after being granted. It creates an immutable audit trail for every release, available on demand at any time an auditor asks.
❹ Post-Deployment Monitoring
A Trusted Release in production is not a permanent, static designation — it is a dynamically updated assessment. AppTrust continuously monitors deployed versions for newly disclosed vulnerabilities (CVEs). When a new vulnerability affects a component included in a deployed application, the system immediately generates an alert with full context: which version is affected, which environments are exposed, and what the remediation priority is.
JFrog Xray’s Contextual Analysis capability further reduces noise by verifying whether the first-party code actually calls the vulnerable function — eliminating false alerts for libraries present in the dependency tree but never invoked at runtime.
Step by Step: Building a Trusted Release in AppTrust
Step ❶: Project and Lifecycle Setup
AppTrust implementation begins by defining a project — the top-level container grouping applications, policies, and lifecycle stages. A project typically maps to a team, product line, or business initiative.
Within the project, a lifecycle stage sequence is defined. A typical configuration includes DEV, QA, STAGING, and PROD. Stages can be customized to fit the organization’s workflow; there are no forced templates.
Step ❷: Creating the Application Entity
The application definition is created next, assigning a business owner, criticality level, and organizational context. This mapping determines how AppTrust prioritizes alerts and reports — a vulnerability in a critical payment application will be treated differently from the same vulnerability in an internal developer tool.
Step ❸: Artifact Binding via OIDC
CI/CD pipeline integration happens by binding built artifacts to the application entity using the OpenID Connect (OIDC) protocol. This binding ties each artifact to its source code commit, ensuring verifiable provenance — who built it, from what code, when, and in what environment.
Step ❹: Defining Policies and Gates
Policies are defined at the entry and exit of each stage. A few examples from real-world configurations:
- DEV → QA gate: no secrets detected in code (JFrog Advanced Security scan result), unit test coverage above defined threshold (SonarQube), code reviewer approval (GitHub);
- QA → STAGING gate: no critical vulnerabilities or documented risk acceptance, complete SBOM generated by Xray, positive integration test results;
- STAGING → PROD gate: approved change request in ITSM (ServiceNow), artifact provenance verification (SLSA), no new critical CVEs since last scan.;
Step ❺: Automatic Evidence Collection
As the CI/CD pipeline runs build and test stages, AppTrust automatically collects results as evidence linked to the specific application version. Developers do nothing manually — the platform collects, cryptographically signs, and archives evidence in real time. Manual attestation is only required in cases demanding human judgment, such as CISO-level risk acceptance.
Step ❻: Promoting Through Stages
When a version satisfies all policies at a stage’s gates, an authorized user (or an automated process) promotes it to the next stage. Every promotion is recorded with a timestamp, user identity, and the set of collected evidence — creating an irreversible entry in the audit trail.
Step ❼: Certification as a Trusted Release
When a version successfully passes through all stages to production, it receives Trusted Release status. From that point, it is continuously monitored — and an auditor can verify the complete history at any time: which policies were required, what evidence was collected, who approved each stage, and how long each step took.
Integrations and Partner Ecosystem
AppTrust is designed as a governance layer that integrates existing tools rather than replacing them. The current partner ecosystem includes leading industry tools:
- GitHub – evidence of reviewer code approval, check statuses, and artifact provenance metadata;
- ServiceNow – change management integration: a gate requires an approved ITSM ticket before production promotion;
- SonarQube – code quality evidence: static scan results, test coverage thresholds, technical debt metrics;
- JFrog Xray – native integration: automatic SBOM generation, vulnerability scanning, license analysis, contextual CVE analysis.
Evidence can also be generated by JFrog-developed reference designs or uploaded manually in structured formats. This format flexibility allows any tool in the organization’s stack to become an evidence source.
Use Cases: Who Uses AppTrust and How
Financial Sector and DORA Compliance
Financial institutions subject to DORA must demonstrate ICT supply chain operational resilience and provide auditors with verifiable evidence of controls. AppTrust automates the collection of this evidence within the normal developer workflow — no separate documentation processes required.
A practical scenario: a bank must prove to its regulator that every version of transaction-processing software underwent a security scan, penetration testing, and a formal change approval process. AppTrust collects this evidence automatically and generates a compliance report with a single click, rather than engaging multiple teams for weeks.
NIST SSDF Compliance and Policy as Code
JFrog published a guide in April 2026 on automating NIST SSDF (Secure Software Development Framework) compliance using AppTrust and the Rego policy language. Policy as Code allows defining requirements in a versioned, testable, and reusable way — just like application code itself.
Multi-Team Environments and Microservices
In organizations with hundreds of microservices developed by dozens of teams, tracking security ownership across components is enormously difficult. AppTrust’s application entity automatically maps microservices to business applications with assigned owners — eliminating the situation where nobody knows whose problem a vulnerability is when it appears in a library called by three different services.
AI Model Governance in the Delivery Pipeline
As AI models enter production environments, AppTrust can govern them like any other software component: verifying model provenance, requiring evidence of risk assessment before deployment, monitoring for new vulnerabilities in inference dependencies. Combined with JFrog AI Catalog and the Agent Skills Registry, this creates a coherent trust chain from code to AI model.
Benefits by Role
AppTrust delivers concrete, role-specific benefits to every stakeholder:
CISO and Security Teams:
- Context-enriched alerts — every vulnerability is linked to an application, owner, and SDLC stage;
- Measurable security value: coverage metrics and mean time to remediation, not just scan counts;
- Continuous post-deployment monitoring with no additional operational overhead.
Development and DevOps Teams:
- No extra forms or parallel processes — evidence collected automatically within the normal CI/CD pipeline;
- Clear ownership: every artifact has an assigned owner and business context;
- Faster feedback: non-compliance detected early, where the cost of remediation is lowest.
GRC and Compliance Teams:
- End of manual post-release audits — the audit trail is built automatically in real time;
- Compliance reports generated instantly, without engaging multiple teams;
- Verifiable evidence instead of declarations — ready for EU AI Act, DORA, NIS2, and NIST SSDF requirements.
Measuring Success: Built-In Analytics
One of AppTrust’s distinguishing features is its built-in analytics based on DORA metrics and security indicators. The insights dashboard presents:
- Deployment frequency – how many certified versions reach production per time period;
- Lead time for changes – how long it takes a version to travel through all SDLC stages;
- Security coverage – what percentage of applications have active policies and gates;
- Vulnerability trend – how the number and severity of findings changes over time;
- Time to remediation – how long it takes to close an identified non-compliance.
These metrics translate security investment into business language: not “we deployed a new scanner,” but “we reduced mean time to remediation for critical vulnerabilities by 40% and increased audit coverage from 30% to 100% of the application portfolio.”
Getting Started: A Practical Adoption Path
Adopting AppTrust does not require overhauling the existing tool stack. A recommended path:
- Pilot on one application – select one critical application, define its entity, map existing tools as evidence sources, configure minimal gates. Goal: achieve a first Trusted Release within 2–4 weeks.
- Expand to the critical application portfolio – using lessons from the pilot, build reusable policy templates and extend coverage to 5–10 of the most critical applications. Goal: standardize the process and eliminate one-off exceptions.
- Automate evidence collection – integrate AppTrust with the CI/CD pipeline so evidence collection is fully hands-off. Remove the last manual steps.
- Full rollout and optimization – gradually cover the entire application portfolio, add gates for AI components, extend policy scope in line with regulatory requirements, and use analytics to continuously optimize the process.
AppTrust is available as an integral part of the JFrog Platform and can be deployed in SaaS or self-hosted mode, in line with the organization’s security policy and regulatory requirements.
The Shift That Matters
The fundamental change AppTrust introduces is simple, though its implications are far-reaching: security and compliance stop being opinions and become facts. An opinion sounds like: “I think this release is secure because our team ran the tests.” A fact sounds like: “Version 4.2.1 received Trusted Release status at 14:37 on May 15, 2026, after successfully passing DEV, QA, and STAGING gates with the following cryptographically signed evidence: [full list available in audit trail].”
In a regulatory environment where demonstrating compliance is a legal obligation — not a matter of goodwill — this difference is not cosmetic. It is the difference between believing something is true and being able to prove it. Auditors, regulators, customers, and boards accept only the latter.
Organizations that invest today in building a verifiable chain of trust in their delivery process are not just satisfying regulatory requirements. They are preparing for a world in which proven software trustworthiness becomes a competitive differentiator as real as time to market or operational costs.
