coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9883a99f788e3bfa428794dc7adae8ec2ac8e6e3
info-tech-canon/infospace/models/devsecops/InfoTechCanonDevSecOpsModel.md

49 KiB
Raw Blame History

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:

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.

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:

ApplicationService
SoftwareSystem
RuntimeResource
Environment
RuntimeWorkload
NetworkEndpoint
DeploymentRecord as landscape/runtime history reference

The DevSecOps Model owns:

Repository
Commit
PullRequest
Pipeline
PipelineRun
Build
TestRun
ScanRun
Artifact
ArtifactVersion
SBOM
Provenance
Attestation
Signature
Release
DeploymentPlan
DeploymentExecution
Promotion
Rollback
DeploymentVerification

Boundary rule:

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:

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:

ScanRun generates SecurityFinding
SBOM evidences ArtifactComposition
Attestation supports SupplyChainAssurance
PolicyGate blocks PipelineRun due to SecurityFinding

3.3 Boundary with Governance

The Governance Model owns:

Policy
Rule
ControlObjective
Control
Decision
Approval
Exception
Evidence
Assurance
Review
RiskAcceptance

The DevSecOps Model references governance when delivery activity is governed.

Examples:

PolicyGate implements Control
ReleaseApproval approves Release
Exception waives PolicyGate
PipelineEvidence supports ControlResult

3.4 Boundary with Task

The Task Model owns:

WorkItem
Task
ReviewTask
ApprovalTask
RemediationTask
ChangeTask
Action
Outcome

DevSecOps may generate, consume, or close work items.

Examples:

PullRequest implements Task
ScanFinding creates RemediationTask
Release requires ApprovalTask
DeploymentFailure creates IncidentTask

3.5 Boundary with Data

The Data Model owns:

Schema
DataContract
DataQualityRule
DataLineage
Dataset
TestData
MigrationData semantics

DevSecOps owns data-related delivery activities.

Examples:

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:

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:

---
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:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

10. Root DevSecOps Taxonomy

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:

id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:

Optional attributes:

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:

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:

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:

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:

pipeline:
trigger:
source_revision:
started_at:
finished_at:
status:
runner:
inputs:
outputs:
logs:
evidence:

Canonical rule:

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:

success
failure
cancelled
skipped
blocked
timed_out
unstable
partial

11.18 TestRun

A TestRun is an execution of tests.

Test types:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

dev -> test
test -> staging
staging -> production
candidate -> approved release

11.49 RolloutStrategy

A RolloutStrategy defines how a deployment or release is introduced.

Examples:

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:

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:

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:

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:

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

draft
open
review_required
changes_requested
approved
merged
closed
rejected
superseded

13.2 Pipeline Run States

queued
running
success
failed
cancelled
skipped
blocked
timed_out
unstable
partial

13.3 Artifact States

created
scanned
signed
attested
published
deprecated
revoked
deleted

13.4 Release States

planned
candidate
under_review
approved
released
deprecated
withdrawn
superseded

13.5 Deployment States

planned
approved
queued
running
succeeded
failed
partially_succeeded
rolled_back
verified
degraded
superseded

13.6 Gate States

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:

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:

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:

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:

Provide a minimal delivery model for a small SaaS platform moving toward production readiness.

Included concepts:

Repository
Branch
Commit
PullRequest
CodeReview
Pipeline
PipelineRun
TestRun
ScanRun
ArtifactVersion
ContainerImage
SBOM
Provenance
Signature
Release
DeploymentRecord
DeploymentVerification
DeliveryMetric

Required relationships:

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:

Map GitHub Actions and GitHub repository events into DevSecOps concepts.

Example mappings:

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:

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:

Map GitLab CI/CD concepts into DevSecOps concepts.

Example mappings:

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:

Represent GitOps delivery to Kubernetes using tools such as Argo CD or Flux.

Included concepts:

Repository
DeploymentManifest
GitOpsApplication
ReconciliationRun
ArtifactVersion
Environment
KubernetesClusterReference
DeploymentRecord
DriftDetection
SyncStatus
Rollback

Example mappings:

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:

Represent build provenance and supply-chain trust levels.

Included concepts:

ArtifactVersion
BuildDefinition
Builder
PipelineRun
Provenance
Attestation
BuildInput
BuildOutput
Signature
TrustLevelReference

Mapping targets:

SLSA
in-toto attestations
Sigstore
SPDX Build Profile

15.7 Seed Profile: SBOM Profile

Purpose:

Represent artifact composition and bill-of-materials evidence.

Included concepts:

ArtifactVersion
SBOM
Component
Dependency
Package
LicenseReference
VulnerabilityReference
VEXReference

Mapping targets:

SPDX
CycloneDX
OSV
GitHub Security Advisories

15.8 Seed Profile: Agentic Delivery Profile

Purpose:

Support software changes generated, reviewed, tested, or deployed with AI/software agents.

Included concepts:

CodingAgentChange
AgentGeneratedPatch
AgentExecutionEvidence
AgentReview
HumanSupervisionReference
ToolUseEvidence
PromptContextReference
TestRun
CodeReview
PolicyGate

Required relationships:

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:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent

16.2 Mapping Record

Example:

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:

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:

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:

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

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:

ApplicationService
SoftwareSystem
Repository
Artifact
Environment
RuntimeResource
DeploymentRecord
RuntimeWorkload
Endpoint

18.2 Organization Model

DevSecOps imports organization concepts for:

maintainer
reviewer
approver
release manager
operator
service owner
platform team
agent supervisor

18.3 Governance Model

DevSecOps imports governance concepts for:

policy gate
release approval
change decision
control objective
exception
evidence
assurance
risk acceptance

18.4 Task Model

DevSecOps imports task concepts for:

work item
pull request task
review task
remediation task
change task
release task
incident task

18.5 Security Model

DevSecOps imports security concepts for:

security finding
vulnerability finding
supply-chain finding
mitigation
security review
security evidence

18.6 Access Control Model

DevSecOps imports access concepts for:

pipeline identity
runner identity
deploy permission
release approval access
agent access
break-glass deployment access

18.7 Data Model

DevSecOps imports data concepts for:

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:

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:

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:

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:

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:

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:

info-tech-canon/
  standards/
    devsecops/
      InfoTechCanonDevSecOpsModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/

Seed files:

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:

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:

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.

Reference in New Issue View Git Blame Copy Permalink