generated from coulomb/repo-seed
2408 lines
49 KiB
Markdown
2408 lines
49 KiB
Markdown
# InfoTechCanon DevSecOps Model
|
|
|
|
**Short Name:** `ITC-DEVSECOPS`
|
|
**Document Status:** Seed Standard Release Candidate 1
|
|
**Version:** RC1-seed
|
|
**Date:** 2026-05-22
|
|
**Repository Context:** `info-tech-canon`
|
|
**Document Type:** InfoTechCanon Domain Standard
|
|
**Intended Audience:** Platform engineers, DevSecOps teams, release engineers, security architects, software architects, SREs, compliance reviewers, service owners, repository maintainers, CI/CD administrators, agentic coding tool designers, and standards authors.
|
|
|
|
---
|
|
|
|
# 1. Purpose
|
|
|
|
The **InfoTechCanon DevSecOps Model** defines a canonical seed model for representing secure software delivery from source change to build, test, scan, package, attest, sign, release, deploy, verify, observe, and improve.
|
|
|
|
It exists to connect software delivery, supply-chain security, governance evidence, runtime landscape knowledge, security findings, data contracts, and operational feedback without forcing every organization into one CI/CD tool, branching model, release process, or deployment method.
|
|
|
|
This standard provides a canonical vocabulary for:
|
|
|
|
- repositories,
|
|
- branches,
|
|
- commits,
|
|
- pull requests,
|
|
- reviews,
|
|
- build definitions,
|
|
- pipelines,
|
|
- pipeline stages,
|
|
- jobs,
|
|
- steps,
|
|
- pipeline runs,
|
|
- quality gates,
|
|
- policy gates,
|
|
- tests,
|
|
- scans,
|
|
- artifacts,
|
|
- artifact versions,
|
|
- packages,
|
|
- container images,
|
|
- IaC modules,
|
|
- deployment manifests,
|
|
- SBOMs,
|
|
- provenance,
|
|
- attestations,
|
|
- signatures,
|
|
- releases,
|
|
- release candidates,
|
|
- deployments,
|
|
- deployment records,
|
|
- environments,
|
|
- promotion,
|
|
- rollback,
|
|
- verification,
|
|
- delivery metrics,
|
|
- and DevSecOps evidence.
|
|
|
|
---
|
|
|
|
# 2. Position in InfoTechCanon
|
|
|
|
The DevSecOps Model is a **domain standard** within InfoTechCanon.
|
|
|
|
It depends on the existing seed standards as follows:
|
|
|
|
```text
|
|
Landscape = services, software systems, runtime resources, environments, deployments.
|
|
Organization = teams, actors, owners, approvers, maintainers, operators.
|
|
Governance = policies, controls, approvals, exceptions, evidence, assurance.
|
|
Task = work items, reviews, remediation, releases, change tasks.
|
|
Tagging = classification of repos, work, findings, releases, and artifacts.
|
|
Access Control = permissions, grants, sessions, agent access, privileged pipeline actions.
|
|
Security = vulnerabilities, findings, supply-chain security, incidents, mitigations.
|
|
Data = data contracts, schemas, test data, migration data, lineage, data quality.
|
|
DevSecOps = delivery flow, pipeline execution, artifacts, provenance, release, deployment.
|
|
```
|
|
|
|
```text
|
|
InfoTechCanon
|
|
├── InfoTechCanonCore
|
|
├── InfoTechCanonLandscapeModel
|
|
├── InfoTechCanonOrganizationModel
|
|
├── InfoTechCanonGovernanceModel
|
|
├── InfoTechCanonTaskModel
|
|
├── InfoTechCanonTaggingStandard
|
|
├── InfoTechCanonAccessControlModel
|
|
├── InfoTechCanonSecurityModel
|
|
├── InfoTechCanonDataModel
|
|
├── InfoTechCanonDevSecOpsModel <-- this standard
|
|
├── InfoTechCanonNetworkModel
|
|
├── InfoTechCanonObservabilityModel
|
|
├── InfoTechCanonPatternLanguage
|
|
└── Application Profiles
|
|
```
|
|
|
|
---
|
|
|
|
# 3. Boundary with Adjacent Standards
|
|
|
|
## 3.1 Boundary with Landscape
|
|
|
|
The Landscape Model owns:
|
|
|
|
```text
|
|
ApplicationService
|
|
SoftwareSystem
|
|
RuntimeResource
|
|
Environment
|
|
RuntimeWorkload
|
|
NetworkEndpoint
|
|
DeploymentRecord as landscape/runtime history reference
|
|
```
|
|
|
|
The DevSecOps Model owns:
|
|
|
|
```text
|
|
Repository
|
|
Commit
|
|
PullRequest
|
|
Pipeline
|
|
PipelineRun
|
|
Build
|
|
TestRun
|
|
ScanRun
|
|
Artifact
|
|
ArtifactVersion
|
|
SBOM
|
|
Provenance
|
|
Attestation
|
|
Signature
|
|
Release
|
|
DeploymentPlan
|
|
DeploymentExecution
|
|
Promotion
|
|
Rollback
|
|
DeploymentVerification
|
|
```
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
DevSecOps owns how changes become artifacts and deployments.
|
|
Landscape owns the runtime system and service context in which deployments exist.
|
|
```
|
|
|
|
## 3.2 Boundary with Security
|
|
|
|
The Security Model owns:
|
|
|
|
```text
|
|
Threat
|
|
Vulnerability
|
|
SecurityFinding
|
|
SupplyChainFinding
|
|
Exposure
|
|
Mitigation
|
|
SecurityIncident
|
|
AttackPath
|
|
SecurityPosture
|
|
```
|
|
|
|
The DevSecOps Model owns the delivery activities and evidence that produce or remediate security-relevant conditions.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
ScanRun generates SecurityFinding
|
|
SBOM evidences ArtifactComposition
|
|
Attestation supports SupplyChainAssurance
|
|
PolicyGate blocks PipelineRun due to SecurityFinding
|
|
```
|
|
|
|
## 3.3 Boundary with Governance
|
|
|
|
The Governance Model owns:
|
|
|
|
```text
|
|
Policy
|
|
Rule
|
|
ControlObjective
|
|
Control
|
|
Decision
|
|
Approval
|
|
Exception
|
|
Evidence
|
|
Assurance
|
|
Review
|
|
RiskAcceptance
|
|
```
|
|
|
|
The DevSecOps Model references governance when delivery activity is governed.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
PolicyGate implements Control
|
|
ReleaseApproval approves Release
|
|
Exception waives PolicyGate
|
|
PipelineEvidence supports ControlResult
|
|
```
|
|
|
|
## 3.4 Boundary with Task
|
|
|
|
The Task Model owns:
|
|
|
|
```text
|
|
WorkItem
|
|
Task
|
|
ReviewTask
|
|
ApprovalTask
|
|
RemediationTask
|
|
ChangeTask
|
|
Action
|
|
Outcome
|
|
```
|
|
|
|
DevSecOps may generate, consume, or close work items.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
PullRequest implements Task
|
|
ScanFinding creates RemediationTask
|
|
Release requires ApprovalTask
|
|
DeploymentFailure creates IncidentTask
|
|
```
|
|
|
|
## 3.5 Boundary with Data
|
|
|
|
The Data Model owns:
|
|
|
|
```text
|
|
Schema
|
|
DataContract
|
|
DataQualityRule
|
|
DataLineage
|
|
Dataset
|
|
TestData
|
|
MigrationData semantics
|
|
```
|
|
|
|
DevSecOps owns data-related delivery activities.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
MigrationRun applies DatabaseMigration
|
|
ContractTest validates DataContract
|
|
SchemaCheck validates SchemaEvolutionPolicy
|
|
```
|
|
|
|
## 3.6 Boundary with Access Control
|
|
|
|
Access Control owns pipeline permissions, service-account access, agent access, privilege, grants, and authorization decisions.
|
|
|
|
DevSecOps references those when delivery requires access.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
PipelineIdentity has_permission deploy Environment
|
|
AgentAccess permits CodeModificationAction
|
|
BreakGlassAccess authorizes EmergencyDeployment
|
|
```
|
|
|
|
---
|
|
|
|
# 4. Research Basis and External Alignment
|
|
|
|
This seed standard draws on multiple DevSecOps and software supply-chain bodies of knowledge.
|
|
|
|
## 4.1 DevOps and DORA Metrics
|
|
|
|
DORA software delivery performance metrics provide a widely used measurement vocabulary around deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. These are valuable delivery-performance mapping targets.
|
|
|
|
## 4.2 SLSA
|
|
|
|
SLSA defines levels and tracks for software supply-chain security, including provenance and build trust. SLSA provenance describes what built an artifact, what process was used, and what inputs were used.
|
|
|
|
## 4.3 in-toto Attestations
|
|
|
|
in-toto provides a framework for software supply-chain integrity and an attestation framework for verifiable claims about how software was produced.
|
|
|
|
## 4.4 SBOM Standards: SPDX and CycloneDX
|
|
|
|
SPDX is an ISO-recognized open standard for communicating software bill of materials and related provenance, license, security, and system metadata.
|
|
|
|
CycloneDX is an OWASP full-stack Bill of Materials standard with supply-chain capabilities for cyber risk reduction, including SBOM and other BOM types.
|
|
|
|
## 4.5 Sigstore and Artifact Signing
|
|
|
|
Sigstore and Cosign provide practical signing and verification mechanisms, including keyless signing and transparency-log-backed verification for artifacts such as container images.
|
|
|
|
## 4.6 OpenSSF Scorecard and Supply-Chain Health
|
|
|
|
OpenSSF Scorecard assesses open-source projects through automated checks covering source code, builds, dependencies, tests, maintenance, and related supply-chain risk indicators.
|
|
|
|
## 4.7 GitHub Actions, GitLab CI, Jenkins, Tekton, Argo CD, Flux
|
|
|
|
Practical CI/CD and GitOps tooling provides mapping targets for pipelines, workflows, jobs, runners, artifacts, environments, deployments, approvals, releases, and GitOps reconciliation.
|
|
|
|
## 4.8 Feature Flagging and Progressive Delivery
|
|
|
|
OpenFeature provides a vendor-agnostic feature flagging API standard. Feature flags and progressive delivery should be represented as delivery mechanisms that may decouple deployment from release.
|
|
|
|
---
|
|
|
|
# 5. Seed Standard Design Stance
|
|
|
|
This standard is a **seed standard**, not a CI/CD implementation manual.
|
|
|
|
It shall:
|
|
|
|
1. define canonical delivery and supply-chain semantics,
|
|
2. distinguish source change, build, artifact, release, deployment, and runtime state,
|
|
3. support secure delivery evidence,
|
|
4. support provenance, attestations, signatures, and SBOMs,
|
|
5. support pipeline policy gates and quality gates,
|
|
6. support manual, automated, GitOps, and progressive delivery models,
|
|
7. support human and agentic code/change workflows,
|
|
8. map to external tools and standards without becoming subordinate to them,
|
|
9. remain markdown-first and agent-retrievable,
|
|
10. and support future assimilation of CI/CD systems, supply-chain standards, and platform practices.
|
|
|
|
---
|
|
|
|
# 6. Scope
|
|
|
|
## 6.1 In Scope
|
|
|
|
This standard covers canonical representation of:
|
|
|
|
- repositories,
|
|
- source branches,
|
|
- commits,
|
|
- tags,
|
|
- pull requests,
|
|
- code reviews,
|
|
- merge events,
|
|
- build definitions,
|
|
- workflows,
|
|
- pipelines,
|
|
- pipeline stages,
|
|
- jobs,
|
|
- steps,
|
|
- runners,
|
|
- pipeline identities,
|
|
- pipeline runs,
|
|
- build runs,
|
|
- test runs,
|
|
- scan runs,
|
|
- quality gates,
|
|
- policy gates,
|
|
- artifacts,
|
|
- artifact versions,
|
|
- packages,
|
|
- container images,
|
|
- deployment manifests,
|
|
- infrastructure-as-code modules,
|
|
- SBOMs,
|
|
- provenance,
|
|
- attestations,
|
|
- signatures,
|
|
- release candidates,
|
|
- releases,
|
|
- release notes,
|
|
- deployment plans,
|
|
- deployment executions,
|
|
- deployment records,
|
|
- environment promotion,
|
|
- rollout strategies,
|
|
- rollback,
|
|
- deployment verification,
|
|
- delivery metrics,
|
|
- and DevSecOps evidence.
|
|
|
|
## 6.2 Out of Scope
|
|
|
|
This standard does not fully define:
|
|
|
|
- source code semantics,
|
|
- all software architecture concepts,
|
|
- all task and issue management,
|
|
- all security vulnerability semantics,
|
|
- all governance control theory,
|
|
- all runtime landscape modeling,
|
|
- all access-control semantics,
|
|
- all observability telemetry models,
|
|
- all package-manager schemas,
|
|
- every CI/CD vendor schema,
|
|
- or every software-development methodology.
|
|
|
|
Those may be mapped, assimilated, profiled, or handled by adjacent standards.
|
|
|
|
---
|
|
|
|
# 7. Normative Language
|
|
|
|
The following terms are used normatively:
|
|
|
|
- **SHALL** indicates a mandatory rule for conformance.
|
|
- **SHOULD** indicates a recommended practice.
|
|
- **MAY** indicates an optional capability.
|
|
- **MUST NOT** indicates a prohibited practice.
|
|
- **SEED** marks a concept defined provisionally here but open to later refinement.
|
|
- **EXTRACT** marks a concept that may later move to a more specialized standard.
|
|
|
|
---
|
|
|
|
# 8. Core Principles
|
|
|
|
## 8.1 Source Is Not Artifact
|
|
|
|
A repository or commit is not the same thing as a built artifact.
|
|
|
|
## 8.2 Artifact Is Not Deployment
|
|
|
|
An artifact version may exist without being deployed.
|
|
|
|
A deployment is an event or execution that makes an artifact active or available in an environment.
|
|
|
|
## 8.3 Deployment Is Not Release
|
|
|
|
Deployment places a change into an environment.
|
|
|
|
Release makes a capability available or active for consumers.
|
|
|
|
Feature flags and progressive delivery may separate deployment from release.
|
|
|
|
## 8.4 Pipeline Definition Is Not Pipeline Run
|
|
|
|
A pipeline definition describes intended automation.
|
|
|
|
A pipeline run is a concrete execution with inputs, outputs, logs, evidence, and result.
|
|
|
|
## 8.5 Evidence Is First-Class
|
|
|
|
Delivery claims SHOULD be supported by evidence such as logs, test results, scan results, SBOMs, provenance, signatures, approvals, and deployment records.
|
|
|
|
## 8.6 Provenance and Attestation Are Distinct
|
|
|
|
Provenance describes origin and build process.
|
|
|
|
Attestation is a verifiable claim about an artifact, process, result, or control.
|
|
|
|
## 8.7 Secure Delivery Requires Identity
|
|
|
|
Pipeline identities, runners, agents, and deployers SHOULD be represented where they affect trust, authorization, and evidence.
|
|
|
|
## 8.8 Policy Gates Are Governance in Delivery
|
|
|
|
Policy gates implement governance rules in delivery workflows but do not own policy semantics.
|
|
|
|
## 8.9 External Tools Are Mapped, Not Obeyed
|
|
|
|
The DevSecOps Model MAY map to GitHub Actions, GitLab CI, Jenkins, Tekton, Argo CD, Flux, SLSA, in-toto, SPDX, CycloneDX, Sigstore, OpenSSF Scorecard, and similar systems.
|
|
|
|
It MUST NOT subordinate its internal semantics to any single tool or standard.
|
|
|
|
---
|
|
|
|
# 9. Canonical Seed Metadata
|
|
|
|
Every DevSecOps artifact SHOULD support structured metadata.
|
|
|
|
Recommended front matter:
|
|
|
|
```yaml
|
|
---
|
|
id: itc-devsecops:PipelineRun
|
|
type: concept
|
|
standard: InfoTechCanonDevSecOpsModel
|
|
standard_version: RC1-seed
|
|
status: candidate
|
|
canonical_owner: InfoTechCanonDevSecOpsModel
|
|
preferred_label: Pipeline Run
|
|
related:
|
|
- itc-devsecops:Pipeline
|
|
- itc-devsecops:ArtifactVersion
|
|
- itc-devsecops:Attestation
|
|
- itc-gov:Evidence
|
|
mappings:
|
|
- itc-map:pipeline-run-to-github-actions-workflow-run
|
|
---
|
|
```
|
|
|
|
Recommended artifact statuses:
|
|
|
|
```text
|
|
idea
|
|
draft
|
|
candidate
|
|
release-candidate
|
|
adopted
|
|
stable
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended concept statuses:
|
|
|
|
```text
|
|
proposed
|
|
experimental
|
|
candidate
|
|
canonical
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
---
|
|
|
|
# 10. Root DevSecOps Taxonomy
|
|
|
|
```text
|
|
DevSecOpsEntity
|
|
├── SourceEntity
|
|
│ ├── Repository
|
|
│ ├── Branch
|
|
│ ├── Commit
|
|
│ ├── SourceTag
|
|
│ ├── PullRequest
|
|
│ ├── MergeEvent
|
|
│ ├── CodeReview
|
|
│ └── SourceChange
|
|
├── PipelineEntity
|
|
│ ├── Pipeline
|
|
│ ├── PipelineDefinition
|
|
│ ├── PipelineStage
|
|
│ ├── PipelineJob
|
|
│ ├── PipelineStep
|
|
│ ├── PipelineRun
|
|
│ ├── Runner
|
|
│ ├── PipelineIdentity
|
|
│ └── PipelineResult
|
|
├── VerificationEntity
|
|
│ ├── TestRun
|
|
│ ├── TestResult
|
|
│ ├── ScanRun
|
|
│ ├── ScanResult
|
|
│ ├── QualityGate
|
|
│ ├── PolicyGate
|
|
│ ├── GateDecision
|
|
│ └── VerificationEvidence
|
|
├── ArtifactEntity
|
|
│ ├── Artifact
|
|
│ ├── ArtifactVersion
|
|
│ ├── Package
|
|
│ ├── ContainerImage
|
|
│ ├── DeploymentManifest
|
|
│ ├── IaCModule
|
|
│ ├── BuildOutput
|
|
│ └── ArtifactDigest
|
|
├── SupplyChainEvidenceEntity
|
|
│ ├── SBOM
|
|
│ ├── Provenance
|
|
│ ├── Attestation
|
|
│ ├── Signature
|
|
│ ├── TransparencyLogEntry
|
|
│ ├── VEXReference
|
|
│ └── SupplyChainEvidence
|
|
├── ReleaseEntity
|
|
│ ├── ReleaseCandidate
|
|
│ ├── Release
|
|
│ ├── ReleaseVersion
|
|
│ ├── ReleaseNote
|
|
│ ├── ReleaseApprovalReference
|
|
│ └── ReleaseStatus
|
|
├── DeploymentEntity
|
|
│ ├── DeploymentPlan
|
|
│ ├── DeploymentExecution
|
|
│ ├── DeploymentRecord
|
|
│ ├── Promotion
|
|
│ ├── RolloutStrategy
|
|
│ ├── Rollback
|
|
│ ├── DeploymentVerification
|
|
│ └── EnvironmentPromotion
|
|
├── RuntimeFeedbackEntity
|
|
│ ├── DeploymentHealthSignal
|
|
│ ├── ChangeFailure
|
|
│ ├── RecoveryAction
|
|
│ ├── DeliveryMetric
|
|
│ └── FeedbackLoop
|
|
└── AgenticDeliveryEntity
|
|
├── CodingAgentChange
|
|
├── AgentGeneratedPatch
|
|
├── AgentReview
|
|
├── AgentExecutionEvidence
|
|
└── HumanSupervisionReference
|
|
```
|
|
|
|
---
|
|
|
|
# 11. Core Concepts
|
|
|
|
## 11.1 DevSecOpsEntity
|
|
|
|
A **DevSecOpsEntity** is any identifiable concept used to represent secure software delivery, automation, artifacts, release, deployment, provenance, verification, or delivery feedback.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
id:
|
|
entity_type:
|
|
canonical_name:
|
|
display_name:
|
|
lifecycle_state:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Optional attributes:
|
|
|
|
```yaml
|
|
owner:
|
|
steward:
|
|
repository:
|
|
environment:
|
|
source_confidence:
|
|
valid_from:
|
|
valid_to:
|
|
tags:
|
|
external_references:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.2 Repository
|
|
|
|
A **Repository** is a version-controlled source location containing source code, configuration, documentation, pipeline definitions, infrastructure definitions, or other delivery-relevant material.
|
|
|
|
Repository ownership and relationship to software systems may be represented through Landscape and Organization concepts.
|
|
|
|
---
|
|
|
|
## 11.3 Branch
|
|
|
|
A **Branch** is a named line of development in a repository.
|
|
|
|
Branching models are profile-specific.
|
|
|
|
---
|
|
|
|
## 11.4 Commit
|
|
|
|
A **Commit** is an immutable source-control change record.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
commit_hash:
|
|
author:
|
|
committer:
|
|
timestamp:
|
|
repository:
|
|
parent_commits:
|
|
signature_reference:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.5 SourceTag
|
|
|
|
A **SourceTag** is a source-control reference marking a commit or version.
|
|
|
|
This is distinct from InfoTechCanon tags.
|
|
|
|
---
|
|
|
|
## 11.6 PullRequest
|
|
|
|
A **PullRequest** is a proposed change to a repository requiring review, discussion, checks, merge, or rejection.
|
|
|
|
Equivalent tool terms may include merge request or change request.
|
|
|
|
---
|
|
|
|
## 11.7 CodeReview
|
|
|
|
A **CodeReview** is a review of a source change, patch, pull request, or generated code.
|
|
|
|
Governance owns review semantics where formal decision rights are involved. DevSecOps owns the delivery artifact.
|
|
|
|
---
|
|
|
|
## 11.8 SourceChange
|
|
|
|
A **SourceChange** is a change to source-controlled material.
|
|
|
|
A source change may be represented by one or more commits and may implement a Task.
|
|
|
|
---
|
|
|
|
## 11.9 Pipeline
|
|
|
|
A **Pipeline** is a delivery workflow that automates or coordinates build, test, scan, package, release, deployment, verification, or related activities.
|
|
|
|
---
|
|
|
|
## 11.10 PipelineDefinition
|
|
|
|
A **PipelineDefinition** is the declared configuration of a pipeline.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
GitHub Actions workflow file
|
|
GitLab CI YAML
|
|
Jenkinsfile
|
|
Tekton Pipeline
|
|
Argo Workflow
|
|
```
|
|
|
|
---
|
|
|
|
## 11.11 PipelineStage
|
|
|
|
A **PipelineStage** is a logical phase in a pipeline.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
build
|
|
test
|
|
scan
|
|
package
|
|
sign
|
|
publish
|
|
deploy
|
|
verify
|
|
promote
|
|
```
|
|
|
|
---
|
|
|
|
## 11.12 PipelineJob
|
|
|
|
A **PipelineJob** is an executable unit within a pipeline stage.
|
|
|
|
---
|
|
|
|
## 11.13 PipelineStep
|
|
|
|
A **PipelineStep** is a smaller executable unit within a job.
|
|
|
|
---
|
|
|
|
## 11.14 PipelineRun
|
|
|
|
A **PipelineRun** is a concrete execution of a pipeline definition.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
pipeline:
|
|
trigger:
|
|
source_revision:
|
|
started_at:
|
|
finished_at:
|
|
status:
|
|
runner:
|
|
inputs:
|
|
outputs:
|
|
logs:
|
|
evidence:
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
PipelineRun SHOULD be separated from PipelineDefinition.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.15 Runner
|
|
|
|
A **Runner** is the execution environment or agent that performs pipeline jobs or steps.
|
|
|
|
Runners may be hosted, self-hosted, ephemeral, privileged, or isolated.
|
|
|
|
---
|
|
|
|
## 11.16 PipelineIdentity
|
|
|
|
A **PipelineIdentity** is the access-control subject used by a pipeline, job, runner, or deployment activity.
|
|
|
|
This concept references Access Control and should be represented where trust or authorization matters.
|
|
|
|
---
|
|
|
|
## 11.17 PipelineResult
|
|
|
|
A **PipelineResult** is the outcome of a pipeline run, stage, job, or step.
|
|
|
|
Seed result values:
|
|
|
|
```text
|
|
success
|
|
failure
|
|
cancelled
|
|
skipped
|
|
blocked
|
|
timed_out
|
|
unstable
|
|
partial
|
|
```
|
|
|
|
---
|
|
|
|
## 11.18 TestRun
|
|
|
|
A **TestRun** is an execution of tests.
|
|
|
|
Test types:
|
|
|
|
```text
|
|
unit
|
|
integration
|
|
contract
|
|
system
|
|
acceptance
|
|
performance
|
|
security
|
|
regression
|
|
smoke
|
|
chaos
|
|
```
|
|
|
|
---
|
|
|
|
## 11.19 TestResult
|
|
|
|
A **TestResult** is the result of a TestRun.
|
|
|
|
---
|
|
|
|
## 11.20 ScanRun
|
|
|
|
A **ScanRun** is an execution of analysis or scanning.
|
|
|
|
Scan types:
|
|
|
|
```text
|
|
SAST
|
|
DAST
|
|
SCA
|
|
container scan
|
|
IaC scan
|
|
secret scan
|
|
license scan
|
|
SBOM scan
|
|
policy scan
|
|
malware scan
|
|
configuration scan
|
|
```
|
|
|
|
---
|
|
|
|
## 11.21 ScanResult
|
|
|
|
A **ScanResult** is the output of a ScanRun.
|
|
|
|
Scan results may generate Security Findings, Governance Findings, or Quality Findings.
|
|
|
|
---
|
|
|
|
## 11.22 QualityGate
|
|
|
|
A **QualityGate** is a delivery gate based on quality criteria.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
tests pass
|
|
coverage threshold met
|
|
linting passes
|
|
performance threshold met
|
|
contract tests pass
|
|
```
|
|
|
|
---
|
|
|
|
## 11.23 PolicyGate
|
|
|
|
A **PolicyGate** is a delivery gate based on governance, security, compliance, or release policy.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
no critical vulnerabilities
|
|
artifact signed
|
|
SBOM present
|
|
release approved
|
|
change ticket linked
|
|
production deployment window valid
|
|
```
|
|
|
|
---
|
|
|
|
## 11.24 GateDecision
|
|
|
|
A **GateDecision** is the result of evaluating a gate.
|
|
|
|
Seed values:
|
|
|
|
```text
|
|
pass
|
|
fail
|
|
waived
|
|
manual_review_required
|
|
not_applicable
|
|
indeterminate
|
|
```
|
|
|
|
---
|
|
|
|
## 11.25 VerificationEvidence
|
|
|
|
**VerificationEvidence** is evidence produced by test, scan, review, gate, or deployment verification activities.
|
|
|
|
---
|
|
|
|
## 11.26 Artifact
|
|
|
|
An **Artifact** is a delivery output that may be versioned, stored, signed, scanned, released, or deployed.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
package
|
|
container image
|
|
binary
|
|
library
|
|
chart
|
|
deployment manifest
|
|
IaC module
|
|
documentation bundle
|
|
model artifact
|
|
```
|
|
|
|
---
|
|
|
|
## 11.27 ArtifactVersion
|
|
|
|
An **ArtifactVersion** is a specific version or immutable instance of an artifact.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
artifact:
|
|
version:
|
|
digest:
|
|
repository:
|
|
build_reference:
|
|
created_at:
|
|
signature_reference:
|
|
sbom_reference:
|
|
provenance_reference:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.28 Package
|
|
|
|
A **Package** is a distributable artifact in a package ecosystem.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
npm package
|
|
Maven artifact
|
|
PyPI package
|
|
Debian package
|
|
OCI artifact
|
|
```
|
|
|
|
---
|
|
|
|
## 11.29 ContainerImage
|
|
|
|
A **ContainerImage** is a container artifact identified by tag and/or digest.
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Digest SHOULD be used for immutable identity.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.30 DeploymentManifest
|
|
|
|
A **DeploymentManifest** is a declared configuration artifact describing how a system should be deployed.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Kubernetes manifest
|
|
Helm chart values
|
|
Kustomize overlay
|
|
Terraform plan
|
|
Ansible playbook
|
|
CloudFormation template
|
|
```
|
|
|
|
---
|
|
|
|
## 11.31 IaCModule
|
|
|
|
An **IaCModule** is an infrastructure-as-code module or artifact.
|
|
|
|
---
|
|
|
|
## 11.32 ArtifactDigest
|
|
|
|
An **ArtifactDigest** is a cryptographic hash or content-addressable identifier for an artifact.
|
|
|
|
---
|
|
|
|
## 11.33 SBOM
|
|
|
|
A **Software Bill of Materials** is a structured inventory of software components and related metadata for an artifact, product, or system.
|
|
|
|
SBOM concepts may map to SPDX or CycloneDX.
|
|
|
|
---
|
|
|
|
## 11.34 Provenance
|
|
|
|
**Provenance** describes how an artifact was produced, including builder, build process, inputs, and relevant parameters.
|
|
|
|
---
|
|
|
|
## 11.35 Attestation
|
|
|
|
An **Attestation** is a verifiable claim about an artifact, process, result, control, or supply-chain event.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
build provenance attestation
|
|
test result attestation
|
|
scan result attestation
|
|
SBOM attestation
|
|
deployment attestation
|
|
policy compliance attestation
|
|
```
|
|
|
|
---
|
|
|
|
## 11.36 Signature
|
|
|
|
A **Signature** is cryptographic evidence binding identity or key material to an artifact, attestation, or document.
|
|
|
|
---
|
|
|
|
## 11.37 TransparencyLogEntry
|
|
|
|
A **TransparencyLogEntry** is a log entry in an append-only or transparency system used to support verification of signatures, attestations, or supply-chain events.
|
|
|
|
---
|
|
|
|
## 11.38 VEXReference
|
|
|
|
A **VEXReference** is a reference to Vulnerability Exploitability eXchange information describing whether known vulnerabilities affect a product or component in context.
|
|
|
|
---
|
|
|
|
## 11.39 SupplyChainEvidence
|
|
|
|
**SupplyChainEvidence** is evidence supporting trust, integrity, authenticity, composition, provenance, or policy compliance in the software supply chain.
|
|
|
|
---
|
|
|
|
## 11.40 ReleaseCandidate
|
|
|
|
A **ReleaseCandidate** is an artifact set, version, or change set proposed for release.
|
|
|
|
---
|
|
|
|
## 11.41 Release
|
|
|
|
A **Release** is a versioned set of capabilities, artifacts, or changes made available for deployment or consumption.
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Release SHOULD be distinguished from Deployment.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.42 ReleaseVersion
|
|
|
|
A **ReleaseVersion** is the version identifier associated with a release.
|
|
|
|
---
|
|
|
|
## 11.43 ReleaseNote
|
|
|
|
A **ReleaseNote** documents relevant changes, risks, fixes, known issues, migrations, or operational notes for a release.
|
|
|
|
---
|
|
|
|
## 11.44 ReleaseApprovalReference
|
|
|
|
A **ReleaseApprovalReference** points to governance approval, review, or decision records.
|
|
|
|
---
|
|
|
|
## 11.45 DeploymentPlan
|
|
|
|
A **DeploymentPlan** describes intended deployment steps, targets, strategy, dependencies, risk controls, and rollback expectations.
|
|
|
|
---
|
|
|
|
## 11.46 DeploymentExecution
|
|
|
|
A **DeploymentExecution** is a concrete execution of a deployment plan or deployment action.
|
|
|
|
---
|
|
|
|
## 11.47 DeploymentRecord
|
|
|
|
A **DeploymentRecord** is historical evidence that a deployment occurred.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
artifact_version:
|
|
target_environment:
|
|
started_at:
|
|
finished_at:
|
|
actor_or_pipeline:
|
|
status:
|
|
strategy:
|
|
rollback_reference:
|
|
verification_reference:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.48 Promotion
|
|
|
|
**Promotion** is movement of an artifact, release candidate, configuration, or deployment from one environment or maturity level to another.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
dev -> test
|
|
test -> staging
|
|
staging -> production
|
|
candidate -> approved release
|
|
```
|
|
|
|
---
|
|
|
|
## 11.49 RolloutStrategy
|
|
|
|
A **RolloutStrategy** defines how a deployment or release is introduced.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
all-at-once
|
|
rolling
|
|
blue-green
|
|
canary
|
|
feature-flagged
|
|
progressive
|
|
dark launch
|
|
shadow
|
|
```
|
|
|
|
---
|
|
|
|
## 11.50 Rollback
|
|
|
|
A **Rollback** is a deployment or release action intended to return to a previous known-good state or disable a faulty change.
|
|
|
|
---
|
|
|
|
## 11.51 DeploymentVerification
|
|
|
|
**DeploymentVerification** is confirmation that a deployment achieved expected technical and operational conditions.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
smoke test
|
|
health check
|
|
SLO check
|
|
error-rate check
|
|
canary analysis
|
|
synthetic transaction
|
|
operator verification
|
|
```
|
|
|
|
---
|
|
|
|
## 11.52 EnvironmentPromotion
|
|
|
|
**EnvironmentPromotion** is a promotion between environments or environment-like lifecycle stages.
|
|
|
|
---
|
|
|
|
## 11.53 DeploymentHealthSignal
|
|
|
|
A **DeploymentHealthSignal** is an observability or verification signal used to assess deployment health.
|
|
|
|
---
|
|
|
|
## 11.54 ChangeFailure
|
|
|
|
A **ChangeFailure** is a failure caused by a change or deployment that requires remediation, rollback, hotfix, incident response, or recovery.
|
|
|
|
---
|
|
|
|
## 11.55 RecoveryAction
|
|
|
|
A **RecoveryAction** is action taken to restore service or safe operation after a failed change or deployment.
|
|
|
|
---
|
|
|
|
## 11.56 DeliveryMetric
|
|
|
|
A **DeliveryMetric** is a metric used to assess delivery performance, quality, reliability, security, or flow.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
deployment frequency
|
|
change lead time
|
|
change failure rate
|
|
failed deployment recovery time
|
|
pipeline duration
|
|
queue time
|
|
test pass rate
|
|
scan finding rate
|
|
mean time to remediate
|
|
```
|
|
|
|
---
|
|
|
|
## 11.57 FeedbackLoop
|
|
|
|
A **FeedbackLoop** connects runtime results, observability, incidents, findings, user feedback, or delivery metrics back to work, governance, security, or delivery improvements.
|
|
|
|
---
|
|
|
|
## 11.58 CodingAgentChange
|
|
|
|
A **CodingAgentChange** is a source change generated or substantially modified by an AI or software agent.
|
|
|
|
---
|
|
|
|
## 11.59 AgentGeneratedPatch
|
|
|
|
An **AgentGeneratedPatch** is a patch proposed or produced by an agent.
|
|
|
|
---
|
|
|
|
## 11.60 AgentReview
|
|
|
|
An **AgentReview** is a review performed by or on behalf of an agent.
|
|
|
|
---
|
|
|
|
## 11.61 AgentExecutionEvidence
|
|
|
|
**AgentExecutionEvidence** is evidence of agent activity, tool use, prompts, commands, generated patches, tests, or review results.
|
|
|
|
---
|
|
|
|
## 11.62 HumanSupervisionReference
|
|
|
|
A **HumanSupervisionReference** points to the human actor, review, approval, or policy governing agentic delivery work.
|
|
|
|
---
|
|
|
|
# 12. Core Relationship Vocabulary
|
|
|
|
Recommended root relationship types:
|
|
|
|
```text
|
|
contains
|
|
part_of
|
|
derived_from
|
|
built_from
|
|
triggered_by
|
|
executes
|
|
produces
|
|
consumes
|
|
uses
|
|
tests
|
|
scans
|
|
generates
|
|
blocks
|
|
passes
|
|
fails
|
|
waives
|
|
attests
|
|
signs
|
|
verifies
|
|
publishes
|
|
releases
|
|
deploys
|
|
promotes
|
|
rolls_back
|
|
verifies_deployment
|
|
evidenced_by
|
|
implements
|
|
fixes
|
|
remediates
|
|
affects
|
|
maps_to
|
|
```
|
|
|
|
Relationship records SHOULD support:
|
|
|
|
```yaml
|
|
id:
|
|
relationship_type:
|
|
source_entity:
|
|
target_entity:
|
|
scope:
|
|
valid_from:
|
|
valid_to:
|
|
source_system:
|
|
confidence:
|
|
evidence:
|
|
rationale:
|
|
```
|
|
|
|
---
|
|
|
|
# 13. DevSecOps State Models
|
|
|
|
## 13.1 Pull Request States
|
|
|
|
```text
|
|
draft
|
|
open
|
|
review_required
|
|
changes_requested
|
|
approved
|
|
merged
|
|
closed
|
|
rejected
|
|
superseded
|
|
```
|
|
|
|
## 13.2 Pipeline Run States
|
|
|
|
```text
|
|
queued
|
|
running
|
|
success
|
|
failed
|
|
cancelled
|
|
skipped
|
|
blocked
|
|
timed_out
|
|
unstable
|
|
partial
|
|
```
|
|
|
|
## 13.3 Artifact States
|
|
|
|
```text
|
|
created
|
|
scanned
|
|
signed
|
|
attested
|
|
published
|
|
deprecated
|
|
revoked
|
|
deleted
|
|
```
|
|
|
|
## 13.4 Release States
|
|
|
|
```text
|
|
planned
|
|
candidate
|
|
under_review
|
|
approved
|
|
released
|
|
deprecated
|
|
withdrawn
|
|
superseded
|
|
```
|
|
|
|
## 13.5 Deployment States
|
|
|
|
```text
|
|
planned
|
|
approved
|
|
queued
|
|
running
|
|
succeeded
|
|
failed
|
|
partially_succeeded
|
|
rolled_back
|
|
verified
|
|
degraded
|
|
superseded
|
|
```
|
|
|
|
## 13.6 Gate States
|
|
|
|
```text
|
|
not_evaluated
|
|
passed
|
|
failed
|
|
waived
|
|
manual_review_required
|
|
indeterminate
|
|
```
|
|
|
|
---
|
|
|
|
# 14. DevSecOps Patterns
|
|
|
|
## 14.1 Pattern: Commit-to-Runtime Trace
|
|
|
|
**Context:** A team needs to know what source produced a running workload.
|
|
|
|
**Problem:** Runtime systems often cannot reliably answer which commit, build, artifact, scan, approval, and deployment produced a workload.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
Commit
|
|
-> PipelineRun
|
|
-> ArtifactVersion
|
|
-> SBOM / Provenance / Attestation / Signature
|
|
-> Release
|
|
-> DeploymentRecord
|
|
-> RuntimeWorkload
|
|
```
|
|
|
|
---
|
|
|
|
## 14.2 Pattern: Build Once, Promote
|
|
|
|
**Context:** Artifacts move through multiple environments.
|
|
|
|
**Problem:** Rebuilding per environment weakens provenance and introduces drift.
|
|
|
|
**Solution:** Build an immutable artifact once, then promote the same artifact through environments with environment-specific configuration and evidence.
|
|
|
|
---
|
|
|
|
## 14.3 Pattern: Policy Gate with Exception
|
|
|
|
**Context:** Delivery must enforce governance and security requirements.
|
|
|
|
**Problem:** Hard gates block urgent change; soft gates become meaningless.
|
|
|
|
**Solution:** Use PolicyGate with explicit Governance Exception, scope, approver, evidence, expiry, and compensating control.
|
|
|
|
---
|
|
|
|
## 14.4 Pattern: Provenance-Carrying Artifact
|
|
|
|
**Context:** Consumers need to trust artifacts.
|
|
|
|
**Problem:** Artifacts without provenance cannot explain source, builder, inputs, or process.
|
|
|
|
**Solution:** Attach provenance and attestations to artifact versions and verify them before promotion or deployment.
|
|
|
|
---
|
|
|
|
## 14.5 Pattern: SBOM-to-Finding-to-Remediation
|
|
|
|
**Context:** Dependency vulnerabilities are discovered.
|
|
|
|
**Problem:** Teams cannot connect dependency findings to runtime services and remediation work.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
SBOM
|
|
-> Component
|
|
-> VulnerabilityFinding
|
|
-> Affected ArtifactVersion
|
|
-> DeploymentRecord / RuntimeWorkload
|
|
-> RemediationTask
|
|
-> VerificationEvidence
|
|
```
|
|
|
|
---
|
|
|
|
## 14.6 Pattern: Deployment Is Not Release
|
|
|
|
**Context:** Feature flags and progressive delivery are used.
|
|
|
|
**Problem:** Teams confuse deployed code with released capability.
|
|
|
|
**Solution:** Model Deployment and Release separately and connect feature flag activation or exposure as release-related events.
|
|
|
|
---
|
|
|
|
## 14.7 Pattern: Delivery Feedback Loop
|
|
|
|
**Context:** Delivery performance and runtime reliability affect each other.
|
|
|
|
**Problem:** CI/CD metrics are disconnected from incidents and SLOs.
|
|
|
|
**Solution:** Connect deployment records to observability signals, incidents, change failures, recovery actions, and delivery metrics.
|
|
|
|
---
|
|
|
|
## 14.8 Pattern: Agentic Change with Supervision
|
|
|
|
**Context:** Coding agents generate changes.
|
|
|
|
**Problem:** Agent output may lack accountability, authority, or evidence.
|
|
|
|
**Solution:** Model agent-generated patches with supervising actor, prompt/context evidence, tool-use evidence, tests, review, and human approval where required.
|
|
|
|
---
|
|
|
|
## 14.9 Pattern: Deployment Verification Before Closure
|
|
|
|
**Context:** Pipelines report deployment success.
|
|
|
|
**Problem:** Deployment success may only mean "command completed", not "service healthy".
|
|
|
|
**Solution:** Require DeploymentVerification based on runtime health, SLOs, smoke tests, canary analysis, or operator confirmation.
|
|
|
|
---
|
|
|
|
# 15. DevSecOps Profiles
|
|
|
|
## 15.1 Profile Format
|
|
|
|
A DevSecOps Profile SHALL declare:
|
|
|
|
```yaml
|
|
id:
|
|
profile_name:
|
|
status:
|
|
implements:
|
|
- InfoTechCanonDevSecOpsModel
|
|
target_context:
|
|
included_concepts:
|
|
required_relationships:
|
|
required_metadata:
|
|
state_model:
|
|
source_of_truth_rules:
|
|
mapping_files:
|
|
validation_rules:
|
|
examples:
|
|
known_deviations:
|
|
```
|
|
|
|
---
|
|
|
|
## 15.2 Seed Profile: Small SaaS DevSecOps Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Provide a minimal delivery model for a small SaaS platform moving toward production readiness.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Repository
|
|
Branch
|
|
Commit
|
|
PullRequest
|
|
CodeReview
|
|
Pipeline
|
|
PipelineRun
|
|
TestRun
|
|
ScanRun
|
|
ArtifactVersion
|
|
ContainerImage
|
|
SBOM
|
|
Provenance
|
|
Signature
|
|
Release
|
|
DeploymentRecord
|
|
DeploymentVerification
|
|
DeliveryMetric
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
PullRequest contains Commit
|
|
PipelineRun triggered_by Commit
|
|
PipelineRun produces ArtifactVersion
|
|
ArtifactVersion described_by SBOM
|
|
ArtifactVersion attested_by Provenance
|
|
ArtifactVersion signed_by Signature
|
|
DeploymentRecord deploys ArtifactVersion
|
|
DeploymentVerification verifies DeploymentRecord
|
|
DeliveryMetric measures DeliveryFlow
|
|
```
|
|
|
|
---
|
|
|
|
## 15.3 Seed Profile: GitHub Actions Delivery Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map GitHub Actions and GitHub repository events into DevSecOps concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
Repository -> Repository
|
|
Branch -> Branch
|
|
Commit -> Commit
|
|
Pull Request -> PullRequest
|
|
Workflow -> PipelineDefinition
|
|
Workflow Run -> PipelineRun
|
|
Job -> PipelineJob
|
|
Step -> PipelineStep
|
|
Runner -> Runner
|
|
Artifact -> BuildOutput / Artifact
|
|
Environment -> DeploymentTarget / EnvironmentReference
|
|
Deployment -> DeploymentRecord
|
|
Check Run -> GateDecision / TestResult / ScanResult
|
|
Release -> Release
|
|
```
|
|
|
|
Known deviations:
|
|
|
|
```text
|
|
GitHub workflow artifacts are not always deployable artifacts.
|
|
GitHub labels belong to Tagging.
|
|
GitHub environments can combine deployment target, protection rules, and approval semantics.
|
|
```
|
|
|
|
---
|
|
|
|
## 15.4 Seed Profile: GitLab CI Delivery Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Map GitLab CI/CD concepts into DevSecOps concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
Project -> Repository / ProjectReference
|
|
Pipeline -> PipelineRun
|
|
.gitlab-ci.yml -> PipelineDefinition
|
|
Stage -> PipelineStage
|
|
Job -> PipelineJob
|
|
Runner -> Runner
|
|
Artifact -> BuildOutput / Artifact
|
|
Environment -> EnvironmentReference
|
|
Release -> Release
|
|
Deployment -> DeploymentRecord
|
|
```
|
|
|
|
---
|
|
|
|
## 15.5 Seed Profile: Kubernetes GitOps Delivery Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent GitOps delivery to Kubernetes using tools such as Argo CD or Flux.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Repository
|
|
DeploymentManifest
|
|
GitOpsApplication
|
|
ReconciliationRun
|
|
ArtifactVersion
|
|
Environment
|
|
KubernetesClusterReference
|
|
DeploymentRecord
|
|
DriftDetection
|
|
SyncStatus
|
|
Rollback
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
Git commit -> Declared desired state
|
|
Argo CD Application / Flux Kustomization -> GitOpsApplication
|
|
Sync operation -> DeploymentExecution
|
|
Kubernetes workload state -> Landscape observed state
|
|
Drift -> DeploymentFinding / Landscape drift finding
|
|
```
|
|
|
|
---
|
|
|
|
## 15.6 Seed Profile: SLSA / Provenance Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent build provenance and supply-chain trust levels.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
ArtifactVersion
|
|
BuildDefinition
|
|
Builder
|
|
PipelineRun
|
|
Provenance
|
|
Attestation
|
|
BuildInput
|
|
BuildOutput
|
|
Signature
|
|
TrustLevelReference
|
|
```
|
|
|
|
Mapping targets:
|
|
|
|
```text
|
|
SLSA
|
|
in-toto attestations
|
|
Sigstore
|
|
SPDX Build Profile
|
|
```
|
|
|
|
---
|
|
|
|
## 15.7 Seed Profile: SBOM Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Represent artifact composition and bill-of-materials evidence.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
ArtifactVersion
|
|
SBOM
|
|
Component
|
|
Dependency
|
|
Package
|
|
LicenseReference
|
|
VulnerabilityReference
|
|
VEXReference
|
|
```
|
|
|
|
Mapping targets:
|
|
|
|
```text
|
|
SPDX
|
|
CycloneDX
|
|
OSV
|
|
GitHub Security Advisories
|
|
```
|
|
|
|
---
|
|
|
|
## 15.8 Seed Profile: Agentic Delivery Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Support software changes generated, reviewed, tested, or deployed with AI/software agents.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
CodingAgentChange
|
|
AgentGeneratedPatch
|
|
AgentExecutionEvidence
|
|
AgentReview
|
|
HumanSupervisionReference
|
|
ToolUseEvidence
|
|
PromptContextReference
|
|
TestRun
|
|
CodeReview
|
|
PolicyGate
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
AgentGeneratedPatch derived_from PromptContextReference
|
|
AgentGeneratedPatch implements Task
|
|
AgentExecutionEvidence evidences CodingAgentChange
|
|
HumanSupervisionReference governs AgenticChange
|
|
CodeReview reviews AgentGeneratedPatch
|
|
PolicyGate gates AgenticChange
|
|
```
|
|
|
|
---
|
|
|
|
# 16. Mapping Model for the DevSecOps Standard
|
|
|
|
Mappings relate InfoTechCanon DevSecOps concepts to external standards, tools, and products.
|
|
|
|
## 16.1 Mapping Types
|
|
|
|
Recommended mapping types:
|
|
|
|
```text
|
|
exactMatch
|
|
closeMatch
|
|
broadMatch
|
|
narrowMatch
|
|
relatedMatch
|
|
conflictMatch
|
|
gapMatch
|
|
derivedFrom
|
|
regulatoryReference
|
|
toolEquivalent
|
|
```
|
|
|
|
## 16.2 Mapping Record
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
id: itc-map:provenance-to-slsa-provenance
|
|
source_concept: itc-devsecops:Provenance
|
|
target_body: SLSA
|
|
target_version: "1.2"
|
|
target_concept: Provenance
|
|
mapping_type: closeMatch
|
|
scope:
|
|
- artifact build provenance
|
|
not_valid_for:
|
|
- all lineage or runtime provenance
|
|
rationale: >
|
|
SLSA provenance describes how an artifact was built, including builder,
|
|
process, and inputs. InfoTechCanon Provenance is generalized but uses SLSA
|
|
provenance as a strong software-supply-chain mapping target.
|
|
confidence: high
|
|
status: candidate
|
|
owner: InfoTechCanonDevSecOpsModel
|
|
```
|
|
|
|
## 16.3 Seed Mapping Targets
|
|
|
|
The DevSecOps Model SHOULD maintain mappings to:
|
|
|
|
```text
|
|
SLSA
|
|
in-toto
|
|
SPDX
|
|
CycloneDX
|
|
Sigstore / Cosign
|
|
OpenSSF Scorecard
|
|
DORA metrics
|
|
GitHub Actions
|
|
GitLab CI
|
|
Jenkins
|
|
Tekton
|
|
Argo CD
|
|
Flux
|
|
Helm
|
|
Kustomize
|
|
Terraform
|
|
OpenFeature
|
|
OCI artifacts
|
|
Docker / container registries
|
|
Maven / npm / PyPI package ecosystems
|
|
SonarQube / CodeQL / SAST tools
|
|
DAST / SCA / IaC scanner schemas
|
|
```
|
|
|
|
---
|
|
|
|
# 17. Assimilation Hooks
|
|
|
|
The DevSecOps Model SHALL be able to receive new delivery, CI/CD, supply-chain, and platform standards through the InfoTechCanon assimilation process.
|
|
|
|
## 17.1 Assimilation Triggers
|
|
|
|
Assimilation may be triggered by:
|
|
|
|
```text
|
|
new CI/CD platform
|
|
new supply-chain standard
|
|
new artifact signing system
|
|
new SBOM format
|
|
new release management practice
|
|
new deployment method
|
|
new GitOps platform
|
|
new coding-agent workflow
|
|
new policy-gate requirement
|
|
new delivery-metric model
|
|
```
|
|
|
|
## 17.2 DevSecOps Assimilation Output
|
|
|
|
A DevSecOps assimilation SHOULD produce:
|
|
|
|
```text
|
|
source summary
|
|
extracted DevSecOps concepts
|
|
concept comparison matrix
|
|
gap list
|
|
conflict list
|
|
mapping file
|
|
candidate new concepts
|
|
candidate relationship changes
|
|
candidate pattern changes
|
|
candidate profile changes
|
|
open questions
|
|
```
|
|
|
|
## 17.3 Recommended First Assimilation Candidates
|
|
|
|
```text
|
|
SLSA 1.2
|
|
in-toto Attestation Framework
|
|
SPDX 3.x
|
|
CycloneDX
|
|
GitHub Actions
|
|
GitLab CI
|
|
Argo CD
|
|
Flux
|
|
OpenSSF Scorecard
|
|
DORA metrics
|
|
Sigstore / Cosign
|
|
OpenFeature
|
|
```
|
|
|
|
---
|
|
|
|
# 18. Integration with Other InfoTechCanon Standards
|
|
|
|
## 18.1 Landscape Model
|
|
|
|
DevSecOps connects to Landscape through:
|
|
|
|
```text
|
|
ApplicationService
|
|
SoftwareSystem
|
|
Repository
|
|
Artifact
|
|
Environment
|
|
RuntimeResource
|
|
DeploymentRecord
|
|
RuntimeWorkload
|
|
Endpoint
|
|
```
|
|
|
|
## 18.2 Organization Model
|
|
|
|
DevSecOps imports organization concepts for:
|
|
|
|
```text
|
|
maintainer
|
|
reviewer
|
|
approver
|
|
release manager
|
|
operator
|
|
service owner
|
|
platform team
|
|
agent supervisor
|
|
```
|
|
|
|
## 18.3 Governance Model
|
|
|
|
DevSecOps imports governance concepts for:
|
|
|
|
```text
|
|
policy gate
|
|
release approval
|
|
change decision
|
|
control objective
|
|
exception
|
|
evidence
|
|
assurance
|
|
risk acceptance
|
|
```
|
|
|
|
## 18.4 Task Model
|
|
|
|
DevSecOps imports task concepts for:
|
|
|
|
```text
|
|
work item
|
|
pull request task
|
|
review task
|
|
remediation task
|
|
change task
|
|
release task
|
|
incident task
|
|
```
|
|
|
|
## 18.5 Security Model
|
|
|
|
DevSecOps imports security concepts for:
|
|
|
|
```text
|
|
security finding
|
|
vulnerability finding
|
|
supply-chain finding
|
|
mitigation
|
|
security review
|
|
security evidence
|
|
```
|
|
|
|
## 18.6 Access Control Model
|
|
|
|
DevSecOps imports access concepts for:
|
|
|
|
```text
|
|
pipeline identity
|
|
runner identity
|
|
deploy permission
|
|
release approval access
|
|
agent access
|
|
break-glass deployment access
|
|
```
|
|
|
|
## 18.7 Data Model
|
|
|
|
DevSecOps imports data concepts for:
|
|
|
|
```text
|
|
data contract
|
|
schema
|
|
schema evolution
|
|
test data
|
|
migration data
|
|
data quality rule
|
|
lineage evidence
|
|
```
|
|
|
|
## 18.8 Observability Model
|
|
|
|
DevSecOps should later integrate with Observability for:
|
|
|
|
```text
|
|
deployment health signal
|
|
change failure
|
|
recovery time
|
|
SLO impact
|
|
runtime verification
|
|
```
|
|
|
|
---
|
|
|
|
# 19. Canon Interface Card Usage
|
|
|
|
Subsystems that implement or produce DevSecOps knowledge SHOULD publish a Canon Interface Card.
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
subsystem: github-actions-importer
|
|
implements:
|
|
- InfoTechCanonDevSecOpsModel
|
|
- GitHubActionsDeliveryProfile
|
|
produces:
|
|
- PipelineRun
|
|
- PipelineJob
|
|
- PipelineStep
|
|
- TestResult
|
|
- BuildOutput
|
|
- DeploymentRecord
|
|
consumes:
|
|
- Repository
|
|
- Commit
|
|
- PullRequest
|
|
- Environment
|
|
relations:
|
|
- PipelineRun triggered_by Commit
|
|
- PipelineRun produces BuildOutput
|
|
- DeploymentRecord deploys ArtifactVersion
|
|
source_of_truth:
|
|
workflow_run_state: GitHub Actions
|
|
known_deviations:
|
|
- workflow artifacts may not be canonical artifacts
|
|
- environment approval semantics require Governance mapping
|
|
```
|
|
|
|
---
|
|
|
|
# 20. Retrieval Requirements
|
|
|
|
The DevSecOps Model is designed for markdown-based infospaces.
|
|
|
|
## 20.1 Required Retrieval Properties
|
|
|
|
Every major concept SHOULD provide:
|
|
|
|
- stable heading,
|
|
- stable identifier,
|
|
- short definition,
|
|
- longer explanation,
|
|
- examples,
|
|
- distinction notes,
|
|
- relationship examples,
|
|
- mapping hooks,
|
|
- profile references,
|
|
- and common mistakes.
|
|
|
|
## 20.2 Agent Brief
|
|
|
|
A mature DevSecOps Model SHOULD include an `agent-brief.md` file with:
|
|
|
|
```text
|
|
purpose
|
|
scope
|
|
owned concepts
|
|
imported concepts
|
|
core distinctions
|
|
do / do not rules
|
|
relationship patterns
|
|
minimal examples
|
|
common mistakes
|
|
profile list
|
|
mapping list
|
|
```
|
|
|
|
## 20.3 Indexes
|
|
|
|
The DevSecOps information space SHOULD provide indexes by:
|
|
|
|
```text
|
|
concept
|
|
relationship
|
|
repository
|
|
pipeline
|
|
artifact
|
|
release
|
|
deployment
|
|
environment
|
|
evidence type
|
|
profile
|
|
pattern
|
|
mapping target
|
|
status
|
|
source system
|
|
```
|
|
|
|
---
|
|
|
|
# 21. Conformance Levels
|
|
|
|
## 21.1 Reference-Conformant
|
|
|
|
A document or system is reference-conformant if it uses DevSecOps Model terminology consistently but does not implement structured metadata or validation rules.
|
|
|
|
## 21.2 Metadata-Conformant
|
|
|
|
A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.
|
|
|
|
## 21.3 Traceability-Conformant
|
|
|
|
A system is traceability-conformant if it can connect source change, pipeline run, artifact version, release, deployment, and runtime target.
|
|
|
|
## 21.4 Evidence-Conformant
|
|
|
|
A system is evidence-conformant if builds, tests, scans, gates, releases, and deployments are linked to evidence.
|
|
|
|
## 21.5 Supply-Chain-Conformant
|
|
|
|
A system is supply-chain-conformant if artifact versions can be connected to SBOMs, provenance, attestations, signatures, and verification results.
|
|
|
|
## 21.6 Profile-Conformant
|
|
|
|
A system is profile-conformant if it implements a declared DevSecOps Profile and passes its validation rules.
|
|
|
|
## 21.7 Assimilation-Conformant
|
|
|
|
A system or repository is assimilation-conformant if it can accept external DevSecOps concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.
|
|
|
|
---
|
|
|
|
# 22. Validation Rules
|
|
|
|
Initial validation rules:
|
|
|
|
```text
|
|
VAL-DEVSECOPS-001: Repository, Commit, ArtifactVersion, Release, DeploymentRecord, and RuntimeWorkload SHOULD be modeled as distinct concepts.
|
|
|
|
VAL-DEVSECOPS-002: PipelineDefinition SHOULD be distinguished from PipelineRun.
|
|
|
|
VAL-DEVSECOPS-003: PipelineRun SHOULD reference source revision and produced outputs where available.
|
|
|
|
VAL-DEVSECOPS-004: ArtifactVersion SHOULD include immutable identity such as digest where available.
|
|
|
|
VAL-DEVSECOPS-005: ContainerImage SHOULD use digest for immutable identity when used for deployment or evidence.
|
|
|
|
VAL-DEVSECOPS-006: ArtifactVersion SHOULD reference SBOM, provenance, attestation, and signature where available.
|
|
|
|
VAL-DEVSECOPS-007: ScanResult SHOULD reference the ScanRun and target artifact/source/configuration it scanned.
|
|
|
|
VAL-DEVSECOPS-008: PolicyGate SHOULD reference Governance Policy, Rule, Control, or Exception where applicable.
|
|
|
|
VAL-DEVSECOPS-009: GateDecision SHOULD record pass/fail/waived/indeterminate state and evidence.
|
|
|
|
VAL-DEVSECOPS-010: DeploymentRecord SHOULD reference artifact version, target environment, actor or pipeline, time, and result.
|
|
|
|
VAL-DEVSECOPS-011: Deployment SHOULD NOT be treated as identical to Release.
|
|
|
|
VAL-DEVSECOPS-012: Rollback SHOULD reference the failed or superseded deployment where possible.
|
|
|
|
VAL-DEVSECOPS-013: DeploymentVerification SHOULD reference runtime or observability evidence where available.
|
|
|
|
VAL-DEVSECOPS-014: AgentGeneratedPatch SHOULD reference supervising actor, task, evidence, and review expectation where relevant.
|
|
|
|
VAL-DEVSECOPS-015: DeliveryMetric SHOULD declare measurement definition and source.
|
|
|
|
VAL-DEVSECOPS-016: Imported external delivery concepts SHOULD be represented through mapping records rather than silently reused.
|
|
|
|
VAL-DEVSECOPS-017: Profiles MUST NOT redefine canonical concepts. They may constrain them.
|
|
|
|
VAL-DEVSECOPS-018: Source tags MUST NOT be confused with InfoTechCanon tagging concepts.
|
|
```
|
|
|
|
---
|
|
|
|
# 23. Anti-Patterns
|
|
|
|
## 23.1 Commit Equals Deployment
|
|
|
|
Assuming that merging code means a change is running.
|
|
|
|
## 23.2 Artifact Without Identity
|
|
|
|
Publishing artifacts without immutable digest or version identity.
|
|
|
|
## 23.3 Pipeline Run Without Evidence
|
|
|
|
Running CI/CD without preserving logs, outputs, test results, scan results, or gate decisions.
|
|
|
|
## 23.4 Deployment Equals Release
|
|
|
|
Treating deployed code as released capability when feature flags or progressive delivery are used.
|
|
|
|
## 23.5 Rebuild Per Environment
|
|
|
|
Rebuilding artifacts in each environment and losing provenance.
|
|
|
|
## 23.6 Scanner Dashboard Graveyard
|
|
|
|
Producing scan findings without linking them to artifacts, runtime impact, remediation tasks, or verification.
|
|
|
|
## 23.7 Policy Gate Theater
|
|
|
|
Adding gates that can be bypassed without exception records, evidence, or review.
|
|
|
|
## 23.8 Unsigned Trust
|
|
|
|
Trusting artifacts without provenance, signature, attestation, or source traceability.
|
|
|
|
## 23.9 Tool-Native Capture
|
|
|
|
Letting GitHub, GitLab, Jenkins, or Argo CD define the internal delivery model.
|
|
|
|
## 23.10 Agent Change Without Accountability
|
|
|
|
Allowing agent-generated changes without supervision, evidence, review, or authorization boundaries.
|
|
|
|
---
|
|
|
|
# 24. Initial Repository Placement
|
|
|
|
Recommended repository layout:
|
|
|
|
```text
|
|
info-tech-canon/
|
|
standards/
|
|
devsecops/
|
|
InfoTechCanonDevSecOpsModel.md
|
|
agent-brief.md
|
|
concepts/
|
|
relationships/
|
|
patterns/
|
|
profiles/
|
|
mappings/
|
|
assimilation/
|
|
examples/
|
|
validation/
|
|
```
|
|
|
|
Seed files:
|
|
|
|
```text
|
|
standards/devsecops/InfoTechCanonDevSecOpsModel.md
|
|
standards/devsecops/agent-brief.md
|
|
standards/devsecops/concepts/repository.md
|
|
standards/devsecops/concepts/pipeline-run.md
|
|
standards/devsecops/concepts/artifact-version.md
|
|
standards/devsecops/concepts/sbom.md
|
|
standards/devsecops/concepts/provenance.md
|
|
standards/devsecops/concepts/attestation.md
|
|
standards/devsecops/concepts/release.md
|
|
standards/devsecops/concepts/deployment-record.md
|
|
standards/devsecops/patterns/commit-to-runtime-trace.md
|
|
standards/devsecops/patterns/build-once-promote.md
|
|
standards/devsecops/patterns/provenance-carrying-artifact.md
|
|
standards/devsecops/patterns/deployment-is-not-release.md
|
|
standards/devsecops/profiles/small-saas-devsecops-profile.md
|
|
standards/devsecops/profiles/github-actions-delivery-profile.md
|
|
standards/devsecops/profiles/kubernetes-gitops-delivery-profile.md
|
|
standards/devsecops/profiles/slsa-provenance-profile.md
|
|
standards/devsecops/profiles/sbom-profile.md
|
|
standards/devsecops/mappings/slsa.yaml
|
|
standards/devsecops/mappings/in-toto.yaml
|
|
standards/devsecops/mappings/spdx.yaml
|
|
standards/devsecops/mappings/cyclonedx.yaml
|
|
standards/devsecops/mappings/github-actions.yaml
|
|
```
|
|
|
|
---
|
|
|
|
# 25. Roadmap
|
|
|
|
## Phase 1: Seed Stabilization
|
|
|
|
- Establish this standard as `InfoTechCanonDevSecOpsModel`.
|
|
- Add seed concepts, relationship vocabulary, patterns, and profiles.
|
|
- Define validation rules.
|
|
- Align with Landscape, Governance, Task, Security, Data, Access Control, and Tagging.
|
|
|
|
## Phase 2: First Assimilations
|
|
|
|
Recommended first assimilations:
|
|
|
|
```text
|
|
SLSA 1.2
|
|
in-toto Attestation Framework
|
|
SPDX 3.x
|
|
CycloneDX
|
|
GitHub Actions
|
|
GitLab CI
|
|
Argo CD
|
|
Flux
|
|
OpenSSF Scorecard
|
|
DORA metrics
|
|
Sigstore / Cosign
|
|
OpenFeature
|
|
```
|
|
|
|
## Phase 3: Profile Maturation
|
|
|
|
- Mature Small SaaS DevSecOps Profile.
|
|
- Mature GitHub Actions Delivery Profile.
|
|
- Mature GitLab CI Delivery Profile.
|
|
- Mature Kubernetes GitOps Delivery Profile.
|
|
- Mature SLSA / Provenance Profile.
|
|
- Mature SBOM Profile.
|
|
- Mature Agentic Delivery Profile.
|
|
|
|
## Phase 4: Tooling Integration
|
|
|
|
- Generate concept indexes.
|
|
- Generate agent brief.
|
|
- Create machine-readable YAML/JSON exports.
|
|
- Add validation scripts.
|
|
- Integrate repository, CI/CD, artifact registry, SBOM, scanner, signing, deployment, GitOps, observability, and task systems.
|
|
|
|
## Phase 5: Delivery Intelligence Loop
|
|
|
|
- Connect commits to tasks.
|
|
- Connect artifacts to SBOM/provenance/signature.
|
|
- Connect deployments to runtime and observability.
|
|
- Connect findings to remediation.
|
|
- Connect policy gates to governance.
|
|
- Connect release and deployment outcomes to DORA-style metrics.
|
|
- Connect agentic changes to supervision, review, and evidence.
|
|
|
|
---
|
|
|
|
# 26. Summary
|
|
|
|
The InfoTechCanon DevSecOps Model is the seed standard for representing secure delivery from source change to artifact, evidence, release, deployment, runtime verification, and feedback.
|
|
|
|
Its most important commitments are:
|
|
|
|
```text
|
|
Separate source, pipeline definition, pipeline run, artifact, release, deployment, and runtime state.
|
|
|
|
Treat SBOMs, provenance, attestations, signatures, tests, scans, and gate decisions as first-class evidence.
|
|
|
|
Support secure supply-chain models such as SLSA, in-toto, SPDX, CycloneDX, Sigstore, and OpenSSF Scorecard
|
|
without surrendering internal semantic autonomy.
|
|
|
|
Represent deployment and release separately to support feature flags and progressive delivery.
|
|
|
|
Connect delivery to governance, security, data contracts, access control, landscape runtime state,
|
|
tasks, observability, and agentic coding workflows.
|
|
|
|
Use profiles to make the model practical for GitHub Actions, GitLab CI, GitOps, Kubernetes,
|
|
SBOMs, SLSA provenance, and agentic delivery.
|
|
```
|
|
|
|
This makes the DevSecOps Model a core seed for production readiness, supply-chain trust, secure delivery automation, auditability, and AI-assisted software development.
|