Classified Software Devsecops Engineer

Classified Software DevSecOps Engineer

When to Use

• Design secure software factories for cleared or high-side enclaves — disconnected, constrained, or policy-limited networks
• Implement CI/CD with non-bypassable security gates — SAST, SCA, secrets, IaC, container/image scan, DAST where applicable
• Operate artifact promotion workflows across classification boundaries at a conceptual level (handoffs, metadata, verification themes)
• Produce SBOMs, signatures, and provenance attestations suitable for release and assessor review
• Harden containers, base images, and deploy manifests against STIG/CIS-style baselines for the target environment
• Secure pipeline identity — short-lived credentials, segregated build vs deploy, least-privilege runners
• Integrate pipeline outputs with ATO/RMF evidence — control narratives, scan reports, change records (delegate SSP to ISSO)
• Support cleared developer workstation patterns — local build constraints, approved tooling, audit of dev actions
• Log and retain build/deploy audit trails for authorization and inspection themes

When NOT to Use

• Govern the classified cyber portfolio, inspections, or government escalation → classified-cyber-security-senior-manager
• Own SSP, POA&M, assessor coordination, or authorization package stewardship → information-systems-security-officer-classified-specialist
• Commercial or internet-connected delivery without classified constraints → devsecops or devops
• Validate builds or releases without security-gate or classified-context focus → build-validator
• Execute authorized penetration tests or exploit development → penetration-tester / web-pentester
• Enterprise GRC program, framework mapping, or commercial audit packs only → compliance-specialist / compliance-engineer
• Provision generic cloud/K8s without classified landing-zone or pipeline security lens → infrastructure-engineer / platform-engineer
• Formal verification, proof obligations, or assurance case ownership → software-assurance-formal-methods-specialist

Related skills

Core Workflows

1. Scope and delivery boundary

Clarify classification context, enclave connectivity, who owns authorization artifacts, and which systems the pipeline may touch.

See `references/classified_devsecops_scope.md`.

2. Cleared pipelines and environments

Design runners, repos, secrets, and network placement for disconnected or high-side build/deploy.

See `references/cleared_pipelines_and_environments.md`.

3. Artifact promotion and boundaries

Define promotion stages, verification at handoffs, and metadata needed when artifacts cross policy boundaries (conceptual only).

See `references/artifact_promotion_and_boundaries.md`.

4. Security gates and supply chain

Implement shift-left scans, SBOM/signing, dependency policy, and exception workflows aligned to program baselines.

See `references/security_gates_and_supply_chain.md`.

5. Infrastructure hardening and deploy

Apply IaC guardrails, image baselines, admission policy themes, and STIG/CIS-oriented deploy checks.

See `references/infrastructure_hardening_and_deploy.md`.

6. ATO evidence and operations

Package pipeline evidence for assessors, operate audit logging, and hand off to ISSO/GRC without owning the SSP.

See `references/evidence_ato_and_operations.md`.

Outputs

• Pipeline architecture brief — connectivity model, trust zones, job segregation, secret flow
• Security gate matrix — tools, thresholds, branch rules, exception process
• Promotion runbook — stages, approvals, verification checks, rollback themes
• Release integrity pack — SBOM, signatures/provenance summary, scan attestations for the build
• Deploy hardening checklist — image baseline, IaC scan results, STIG/CIS mapping themes
• Evidence index for assessors — artifact list, retention, control pointers (for ISSO ingestion)

Principles

• Delivery engineer lens — implement and evidence secure factories; do not substitute for ISSO or program management
• Policy-first — follow program-specific classification, cross-domain, and tooling rules; describe patterns, not classified procedures
• Non-bypassable gates — protected branches and segregated deploy jobs; no silent skips on production paths
• Integrity by default — SBOM + signing on every production-eligible artifact; verify at deploy
• Minimum necessary in chat — no real tenant IDs, payloads, or export-controlled technical dumps in artifacts
• Evidence, not assertion — tie recommendations to scan results, logs, and control mapping themes

When to load references

• Role boundary and handoffs → references/classified_devsecops_scope.md
• Air-gapped / high-side CI runners → references/cleared_pipelines_and_environments.md
• Promotion and boundary handoffs → references/artifact_promotion_and_boundaries.md
• SAST/SCA/secrets/SBOM gates → references/security_gates_and_supply_chain.md
• IaC, images, STIG/CIS deploy → references/infrastructure_hardening_and_deploy.md
• ATO evidence and audit operations → references/evidence_ato_and_operations.md

Artifact Promotion and Boundaries

Purpose

Describe conceptual patterns for promoting software artifacts when classification, connectivity, or policy boundaries separate build from consumption—without reproducing program-specific transfer procedures.

Promotion model

Immutable artifacts

• Every release build produces a content-addressed or digest-pinned artifact (container image, package bundle, firmware image)
• Tags are pointers; rollback = promote prior digest, not rebuild old tag in place
• Manifest lists all constituent images/packages with digests

Promotion stages (example)

Adjust names to program vocabulary; keep criteria testable.

Boundary handoff themes

When artifacts cross a classification or connectivity boundary:

1. Manifest — digests, versions, build provenance reference, SBOM location 2. Verification — signature check, hash match, optional human dual-control per policy 3. Labeling — security marking metadata per program rules (not invented in chat) 4. Receipt — downstream logs acceptance; breaks chain if mismatch 5. Separation — build metadata that must not transit is stripped or summarized

Do not document operational steps for cross-domain solutions (CDS), guards, or couriers—route to program engineers and security officers.

Metadata minimums

Dual-control and approvals

• Production promotion may require two approvers from separate roles
• Waivers for failed gates require named owner, expiry, compensating control
• Emergency break-glass documented in change system with retrospective review

Rollback

• Keep N prior production digests warm in registry
• Rollback deploy references prior manifest; re-run smoke tests
• If rollback crosses boundary, same verification as forward promotion
• Incident linkage if rollback due to security defect

Anti-patterns

• Rebuilding "the same version" on the far side without provenance link
• Promoting :latest without digest pin
• Passing source code archives when policy requires binary-only transfer
• Omitting SBOM at boundary because "downstream trusts us"
• Storing customer or mission data inside artifact bundles

Interface with ISSO

At each boundary crossing, ISSO may require:

• Evidence that verification occurred
• Significant change record if artifact type or data flow changed
• Updated architecture diagram reference in SSP (ISSO-owned narrative)

DevSecOps supplies artifacts and logs; ISSO maintains authorization package.

Diagram (logical)

[Build enclave] --signed bundle+SBOM--> [Transfer zone] --verified receipt--> [Consume enclave]
                      |                              |
                 audit log                      audit log

Related workflows

• Cleared runners → cleared_pipelines_and_environments.md
• Signing and SBOM → security_gates_and_supply_chain.md
• Deploy baselines → infrastructure_hardening_and_deploy.md

Classified DevSecOps Scope

Purpose

Define what a classified software DevSecOps engineer owns in secure delivery versus adjacent roles (ISSO, classified cyber senior manager, commercial DevSecOps, platform/IaC).

In scope

Out of scope

• Portfolio-level classified cyber governance, inspection leadership, government escalation
• SSP authorship, POA&M ownership, assessor negotiation as system ISSO
• Enterprise GRC charter, framework selection, commercial SOC 2-only programs
• Hands-on pentest, malware RE, or red-team exploit development
• Legal classification, export control determinations, or contract interpretation

Environment archetypes

Connected enclave (policy-constrained)

• Outbound internet restricted or proxied; artifact repos may be internal mirrors only
• Third-party packages ingested through approved vetting workflows
• CI may reach internal package mirrors but not arbitrary registries

Disconnected / air-gapped build

• Build runners have no route to public internet; dependencies arrive via approved transfer
• Tooling versions pinned; offline vulnerability DBs or periodic sync windows
• Promotion of artifacts uses physical or one-way transfer mechanisms (program-specific)

High-side delivery

• Developers and pipelines operate at higher classification; downstream consumers may be lower
• Promotion requires boundary controls, labeling themes, and verification at handoffs (see artifact promotion reference)
• Never reproduce operational transfer procedures in chat—reference program SOPs

RACI themes (delivery-focused)

R = responsible, A = accountable, C = consulted, I = informed — adjust to program RACI.

Intake questions

1. What is the authorization boundary for systems this pipeline deploys? 2. What connectivity do build runners have (none, proxy, full)? 3. Who signs releases and who approves promotion across stages? 4. Which controls must pipeline evidence satisfy (e.g., CM, SI, SA, RA families at high level)? 5. Are containers in scope? Who owns base image gold standards? 6. What retention applies to build logs and scan artifacts?

Deliverable quality bar

• Architecture diagrams show trust zones, not internal hostnames or tenant IDs
• Gate matrix is testable: tool, trigger, fail/warn, exception owner
• Evidence index maps artifacts to control IDs as pointers for ISSO—not duplicate SSP text

Handoff to ISSO

Provide:

• Last green pipeline run ID (or internal equivalent) per release
• SBOM + signature verification record
• Aggregated scan summary (critical/high open with exceptions)
• Change ticket linking commit → deploy
• Known gaps explicitly listed for POA&M consideration

Anti-patterns

• Treating pipeline green as authorization to operate
• Storing long-lived cloud keys in CI variables on classified programs
• Skipping image scan because builds are "internal only"
• Copying commercial devsecops gate thresholds without program baseline review
• Embedding classification markings or customer data in SBOMs or logs shared broadly

Cleared Pipelines and Environments

Purpose

Design CI/CD runners, source control, secrets, and networking for cleared or high-side software delivery where connectivity and tooling are constrained.

Pipeline topology patterns

Segregated build and deploy

[Source] → [Build job - untrusted] → [Artifact vault] → [Deploy job - trusted] → [Target env]

• Build jobs compile, test, scan; cannot push to production clusters
• Deploy jobs run only on protected branches/tags with environment approvals
• Separate service identities for build vs deploy; deploy identity has minimal blast radius

Staged runners by trust

Air-gapped build loop (conceptual)

1. Approved dependency bundles enter the enclave on program-approved transfer 2. Build consumes only internal mirrors and lockfiles 3. Scans run against offline vulnerability data (synced on schedule) 4. Signed artifacts exit via one-way transfer to downstream stage 5. Document verification at receipt (hash, signature, manifest match)

Source control hardening

• Protected default branch; required reviews and status checks
• No direct pushes; signed commits where program requires
• Branch policies tie merge to pipeline success on same commit SHA
• Submodule and large binary policies aligned with supply-chain vetting
• Audit log retention for clone, push, permission changes

Secrets and credentials

Cleared developer workstation themes

• Builds may occur only on approved images with mandatory endpoint controls
• Local secrets prohibited or confined to hardware-backed stores per policy
• Dependency installs from internal mirrors; document offline workflow for travelers
• Pre-commit hooks optional; authoritative gates remain on server-side CI
• Screen capture, removable media, and remote access rules are personnel/IT—not defined here

Runner hardening checklist

• [ ] OS baseline aligned to program STIG/CIS image (see infrastructure reference)
• [ ] Non-root job execution where supported
• [ ] Ephemeral workers or frequent rebuild to limit persistence
• [ ] No interactive shells on production-path runners
• [ ] Toolchain versions pinned; changes via change control
• [ ] Antivirus/EDR where required; logs forwarded to central store
• [ ] Time sync (NTP) for audit correlation

Network placement

• Build runners in dedicated VLAN/subnet; egress allowlists only
• Artifact registry internal; TLS and auth required
• Package proxies vet upstream (where proxy exists)
• DAST scanners isolated; never pointed at production mission systems without approval

Observability and audit

Log at minimum:

• Job ID, pipeline definition version, commit SHA, actor (service or human)
• Gate results per stage (pass/fail/waived)
• Artifact digest promoted
• Deploy target environment and approval record ID

Retention meets program and control family expectations; ISSO defines authoritative period.

Failure modes

Related workflows

• Security gates and SBOM → security_gates_and_supply_chain.md
• Promotion across boundaries → artifact_promotion_and_boundaries.md
• Evidence packaging → evidence_ato_and_operations.md

Evidence, ATO, and Operations

Purpose

Package pipeline and delivery evidence for RMF/ATO-style assessments without owning the system security plan (SSP). Support ISSO and assessors with traceable artifacts.

DevSecOps vs ISSO boundary

Control families commonly supported by pipeline evidence

High-level mapping themes (exact control IDs vary by baseline):

ISSO maps artifacts to control narratives; DevSecOps maintains index and freshness.

Evidence index template

For each release or assessment period:

## Release: <version> — <date>
- Pipeline run: <id>
- Commit: <sha>
- Artifact digest: <digest>
- SBOM: <path or ticket>
- Signatures: <verification log ref>
- SAST: <report ref>
- SCA: <report ref>
- Container scan: <report ref>
- IaC scan: <report ref if applicable>
- Exceptions: <ticket ids>
- Deploy record: <change id>
- Known open findings: <summary for POA&M consideration>

Store in program-approved repository; no classified payloads in shared trackers unless authorized.

Continuous monitoring hooks

• Weekly: open critical/high in default branch vs production digest
• On dependency upgrade: diff SBOM and re-run full gate suite
• On runner image change: record in change system; attach scan
• On pipeline definition change: treat as significant change candidate for ISSO review

Audit logging requirements

Capture and retain:

Correlate timestamps with central SIEM where integrated.

Assessment support

When assessors request samples:

1. Confirm scope (time window, environments) 2. Export indexed artifacts—redact as required 3. Provide narrative of how gates enforce policy (not classified ops detail) 4. Escalate gaps to ISSO for POA&M, not informal waivers

Operations cadence

Incident themes (pipeline compromise)

If pipeline or registry compromise suspected:

1. Freeze promotions and rotate CI/deploy credentials per IR playbook 2. Preserve logs and artifact manifests 3. Notify ISSO and classified cyber interfaces 4. Rebuild runners from gold images; re-verify all production digests 5. Do not execute destructive cleanup without IR coordination

Technical IR execution → incident-responder; governance → classified-cyber-security-senior-manager.

Related workflows

• Gates and SBOM → security_gates_and_supply_chain.md
• Scope and RACI → classified_devsecops_scope.md

Infrastructure Hardening and Deploy

Table of contents

1. Deploy-layer scope 2. IaC security for classified landing zones 3. Container and image hardening 4. Kubernetes admission themes 5. STIG/CIS mapping at deploy 6. Runtime and network 7. Pre-production checklist

Deploy-layer scope

DevSecOps owns security characteristics of what the pipeline deploys:

• Hardened base images and buildpacks approved for the enclave
• IaC modules scanned before merge
• Manifests enforcing non-root, resource limits, and network policy hooks
• Verification that deploy targets match authorized architecture

Platform teams may own cluster lifecycle; DevSecOps ensures workload deploy path meets program baselines.

IaC security for classified landing zones

Scan on plan: Terraform/Kubernetes/OpenAPI policies in CI; block critical violations.

Drift: Periodic posture scan; pipeline deploy should not disable logging or encryption.

Container and image hardening

Base image program

• Maintain gold images rebuilt on patch cadence
• Document packages included; remove shells/package managers from minimal runtime where feasible
• Scan gold images before publishing to internal registry

Dockerfile / build practices

• Run as non-root user
• Read-only root filesystem where application permits
• Drop Linux capabilities; no privileged
• No secrets in layers; use runtime secret injection
• Pin base image digest in CI build

Kubernetes admission themes

Policy-as-code (OPA Gatekeeper, Kyverno, or cloud-native policies) should enforce:

• Allowed registries only (internal mirrors)
• Required labels and annotations
• Block latest tag for production namespaces
• Require resource requests/limits
• Deny hostPath, hostNetwork, privileged, escalation
• Require network policies for namespaces in scope
• Verify image signatures where supported

Deploy job fails if admission rejects; do not --force without change control.

STIG/CIS mapping at deploy

Produce a mapping spreadsheet from STIG/CIS items to pipeline checks and cluster policies—ISSO incorporates into SSP evidence.

Runtime and network

• Network policies default-deny east-west; explicit allow per service
• Ingress only via approved controllers and WAF themes where required
• Secrets via CSI/external secrets; rotation hooks
• Workload identity for cloud API access; scoped IAM policies

Pre-production checklist

• [ ] IaC scan clean or waivers approved
• [ ] Image scan on exact digest to be deployed
• [ ] Signature verified in deploy job
• [ ] SBOM archived for release
• [ ] STIG/CIS spot checks on sample manifest
• [ ] Network policy applied in staging
• [ ] Logs visible in central SIEM test partition
• [ ] Rollback manifest prepared
• [ ] Change ticket links commit, pipeline run, target environment

Related workflows

• Supply chain signing → security_gates_and_supply_chain.md
• Promotion → artifact_promotion_and_boundaries.md
• Evidence → evidence_ato_and_operations.md

Security Gates and Supply Chain

Table of contents

1. Gate philosophy 2. Pipeline stage order 3. Scan types and defaults 4. SBOM and signing 5. Dependency policy 6. Exceptions and waivers 7. Agentic CI considerations

Gate philosophy

• Gates on protected branches and production deploy paths are non-skippable
• Fail closed on secrets and critical exploitable issues unless documented exception
• Same commit SHA scanned in CI is what gets signed and promoted
• Waivers are time-bound, owned, and visible to ISSO via evidence index

Pipeline stage order

lint → unit test → SAST → SCA → build → IaC scan (if infra change) → image build →
container scan → SBOM → sign/provenance → staging deploy → smoke → [DAST] → prod promote

DAST only where policy allows; never default-scan production mission systems.

Scan types and defaults

False positives

• Require tool + rule ID + file path in ticket
• Prefer global suppressions with expiry over silent ignores in repo
• Revisit suppressions quarterly or on major tool upgrade

SBOM and signing

SBOM (CycloneDX or SPDX)

Include per release:

• Component name, version, purl or coordinates
• Hash of deliverable artifact
• Relationship to parent image/bundle
• No embedded customer data or environment secrets

Signing and provenance

Deploy verification: admission controller or deploy job verifies signature before apply.

Dependency policy

1. Lockfiles required; no floating versions on release branches 2. New dependencies need review ticket (purpose, license, maintainer health) 3. Internal mirrors are source of truth in disconnected enclaves 4. Block typosquat and unpinned Git URLs in manifests 5. Pin CI actions and base images by digest or immutable version

Third-party CI actions

• Allowlist organizations/actions
• Fork and pin if vendor actions required
• Review agentic workflow plugins with same rigor as production code

Exceptions and waivers

Expired waivers fail the pipeline until remediated or renewed.

Agentic CI considerations

When AI coding agents run in CI (e.g., automated fix bots):

• Treat agent output as untrusted until scanned like developer commits
• Restrict agent permissions to least-privilege tokens
• Log prompts and actions where policy allows; never log secrets
• Block agents from modifying pipeline definitions or branch protections without human review
• Pair with agentic-actions-auditor patterns when installed for workflow review

Evidence outputs per release

• Machine-readable scan reports (SARIF or vendor export)
• SBOM file stored with artifact
• Signature verification log
• Exception register snapshot
• Pipeline run URL/ID and commit SHA

Related workflows

• Air-gapped toolchains → cleared_pipelines_and_environments.md
• Deploy verification → infrastructure_hardening_and_deploy.md
• ISSO handoff → evidence_ato_and_operations.md