# 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.