AppTrust Glossary

Following is a glossary of terms related to AppTrust:

  • Activity Log: A feature that provides a comprehensive, searchable, and filterable record of all user activities and key events related to application, version, package, and stage management. Each log entry details who performed the action, when, what they did, and the outcome.

  • AppTrust: A JFrog solution designed to fundamentally transform application lifecycle manage- ment and governance for large enterprises. It resolves the conflict between microservice team autonomy and the need for cohesive, predictable, and auditable application releases, providing a strategic framework, provable quality mechanisms, and automated governance for software delivery.

  • Application: A defined construct within AppTrust representing an application, which is created under a project and associated with labels, owners, builds, and packages. It serves as a central point for managing and tracking the application's attributes and resources.

    • 1st-party application: The application in which you are currently working.
    • 2nd-party application: An application developed by a different team within your organization.
    • 3rd-party application: An application that was developed outside of your organization, including open-source software.
  • Application Governance: The practice of establishing and enforcing policies, procedures, and responsibilities to control and ensure the quality, security, and compliance of applications through- out their lifecycle. AppTrust aims to transform this from manual checklists to cryptographic proof and automated enforcement.

  • Application Lifecycle Management (ALM): The overall process of managing a software application from its initial conception through development, testing, deployment, maintenance, and eventual retirement. AppTrust fundamentally transforms ALM for large enterprises, addressing complexities arising from microservice architectures.

  • Application Release Orchestration (ARO): A practice that automates, sequences, and governs the steps involved in releasing entire applications across stages. It bridges the gap between individual CI/CD pipelines, providing a central nervous system to coordinate complex releases, manage dependencies, enforce governance, and ensure auditability from development to production.

  • Application Version: A specific, identifiable iteration of an application within AppTrust, which can be created from various sources like artifacts, packages, builds, Release Bundles, or other versions. These versions are promoted through defined lifecycle stages, with their progression governed by policies and evidence.

  • Build Phase (SDLC): The phase in the Software Development Lifecycle where source code is compiled into deployable artifacts (e.g., container images), which are then uploaded to JFrog Artifactory along with their build-info. This phase also includes generating and attaching build- related evidence, and culminating in the creation of a signed, immutable application version.

  • Combined Approach: A hybrid microservice release strategy unequivocally recommended by AppTrust for large enterprises, balancing developer autonomy with enterprise governance. It allows individual microservices to have independent lifecycles culminating in internal releases, followed by a separate, unified process for a full platform solution's external release.

  • Code Phase (SDLC): The initial phase of the Software Development Lifecycle where developers write, test, and analyze code locally before committing it to the source control repository. This phase is where the first pieces of evidence, such as static code analysis (SAST) results, are generated and attached to the build record.

  • Coverage: A feature in AppTrust that provides insights into existing breaches by severity and age, and tracks the integration status of expected scanners (e.g., SCA, contextual analysis, exposures, run time) across different stages of the application lifecycle (Curate, PR merge, Commit, Build, Prod, Distribute, Run).

  • DevGovOps: A framework that integrates governance, risk, and compliance (GRC) directly into the DevOps lifecycle and security practices. By automating governance, policies and controls, DevGovOps ensures that software delivery remains both rapid and compliant without trade-offs. This approach shifts traditional governance from a post-development manual checkpoint to a continuous, automated process that bolsters business resilience.

  • Evaluations: A feature in AppTrust that displays the results of lifecycle policy evaluations, indicating whether an action was successful or failed due to policy violations. It provides details like the evaluation time, decision, action, policy stage, resource type, and an overview of scanner types and evaluation outcomes.

  • Evidence Collection: A core capability within JFrog where actions performed on subjects, such as artifacts, packages, builds, Release Bundles, application versions, and so on generate signed, immutable pieces of evidence (e.g., test results, security scan reports), thus creating a verifiable, tamper-proof audit trail.

  • Insights: Dashboards within AppTrust that provide personalized metrics and trends related to applications, such as Security metrics, DORA metrics, application health, lifecycle status, and recent activity trends. These widgets aggregate data at the application or organization level.

  • Release Bundle v2: An immutable, cryptographically signed ledger that serves as the versioned unit for a software release. It encapsulates a defined set of packages and (optionally) their dependencies.

  • Lifecycle Gates: Automated policies within AppTrust that block the promotion of an application version to the next stage unless a specific set of criteria is met. These criteria are defined as queries against the evidence collected and attached to the application version, ensuring governance throughout the SDLC.

  • Lifecycle Policies: Configurable policies within AppTrust that enable the enforcement of governance across the Software Development Lifecycle. They define specific conditions (e.g., malicious package detection, CVE score, evidence existence, package license compliance) and correspond- ing actions (e.g., Block Promotion, Warning) to ensure quality and compliance.

  • Microservice Architecture: A software development approach that structures an application as a collection of small, loosely coupled services, each developed and deployed independently by autonomous teams. While fostering agility, this approach can lead to significant integration challenges and unpredictable production environments in large-scale enterprises.

  • Microservice-level application: A signed, immutable application version  created by each micro- service team after their CI/CD and QA processes are complete, formally representing their internal release. This application version certifies the microservice version is ready for broader consumption or inclusion in a larger platform release.

  • Package Binding: The process of linking a specific package version (e.g., Maven, Docker) to an application within AppTrust. This allows users to view all packages consumed by an application, ensuring traceability and ownership.

  • Platform Release Model: A strategic template for enterprise microservice delivery that treats the entire application (a collection of many microservices) as a single, versioned entity. It is designed to resolve the conflict between developer autonomy and the need for cohesive, predictable, and auditable application releases, often aligning with the cadence of an Agile Release Train.

  • Platform Solution application (Application of Applications): A single, unified "jumbo" application version that references a list of certified, versioned microservice-level applications. This application version serves as the single, governable entity for the entire application's external release and is typically created as a periodic, scheduled event.

  • Promotion Phase (SDLC): The phase of the Software Development Lifecycle where an application version is promoted through a series of stages (e.g., DEV, QA, Staging) to prove its quality. During this phase, the application version undergoes rigorous testing and scanning, with all results captured as signed evidence attached directly to the application version, creating an undeniable audit trail.

  • Quality Gates: Checkpoints in the CI/CD pipeline that enforce specific, measurable quality criteria before a software artifact is allowed to progress to the next stage. They act as automated validation points that prevent poor-quality code, security vulnerabilities, or performance regressions from moving down the software supply chain.

  • Releasable: A package or standalone artifact that will be released to users as part of an application version.

  • Release Phase (SDLC): The formal stage (PROD) where an application version, having successfully passed all lifecycle gates in the promotion phase, is officially "released". This can signify an internal release for consumption within the organization or an external release to customers.

  • Remediation: A feature within AppTrust aimed at addressing detected issues and violations within applications, with its specific functionalities for remediation actions indicated as pending.

  • Semantic Versioning (SemVer): A strict versioning discipline (MA JOR.MINOR.PATCH) that mandates how version numbers are incremented based on the type of change: MAJOR for incompatible API changes, MINOR for backward-compatible new functionality, and PATCH for backward-compatible bug fixes. Adherence to SemVer strongly recommended for automated release management and clarifies the impact of version changes across microservices. For more information, see https://semver.org.

  • Software Bill of Materials (SBOM): A formal, machine-readable inventory of all software compo- nents, including direct and transitive dependencies, within a given software artifact. It is a critical tool for understanding and managing the software supply chain.

  • Stage Categories: Configurable logical checkpoints within AppTrust and JFrog RLM that define the progression path for application versions within the SDLC. Stages can be either project-specific or global, and are categorized as 'code' or 'promote'.

  • Stages: Logical entities within the JFrog platform that represent the maturity steps a release candidate must pass through in an organization's Software Development Lifecycle (SDLC), such as DEV, QA, STAGING, and PROD. Each stage is configured with its own set of associated repositories and permissions.