Feature Request: Container Image Signing, SBOM, and Attestation (attempt 2)

[smecsia]

Feature Request: Container Image Signing, SBOM, and Attestation

Requested by: Everworker DevSecOps Team
Date: 2026-02-03
Priority: High
Category: Security / Supply Chain Integrity

---

Executive Summary

We request the addition of optional container image signing, SBOM generation, and attestation capabilities to Simple Container CLI. This feature would enable organizations to meet modern software supply chain security requirements (NIST SP 800-218, SLSA, Executive Order 14028) directly within their existing sc workflows.

---

Business Justification

Compliance Requirements

Organizations are increasingly required to demonstrate software supply chain security:

Standard	Requirement	Current Gap
NIST SP 800-218 (SSDF)	PS.1.1 - Generate and maintain SBOMs for distributed software	No native SBOM support
NIST SP 800-218 (SSDF)	PS.3.1 - Archive and protect build artifacts	No cryptographic signing
SLSA Level 2+	Signed provenance for builds	No provenance attestation
Executive Order 14028	Software supply chain security for federal contractors	Missing signing/SBOM
CIS Docker Benchmark	5.3.1 - Sign container images	Not available
CIS Docker Benchmark	5.3.4 - Maintain SBOM for images	Not available

Customer Impact

• AWS Marketplace requires signed artifacts for listing
• Enterprise customers require SBOM for procurement
• Government contracts mandate EO 14028 compliance
• Security audits increasingly require supply chain attestation

---

Feature Specification

1. Image Signing (Cosign/Sigstore Integration)

Configuration

# sc stack configuration
signing:
  enabled: true                          # Enable/disable signing (default: false)
  provider: sigstore                     # Signing provider (sigstore, notation, custom)
  keyless: true                          # Use keyless signing via OIDC (recommended)
  # OR explicit key configuration:
  # privateKey: ${secret:cosign-private-key}
  # publicKey: ${secret:cosign-public-key}

  verify:
    enabled: true                        # Verify signatures after signing
    oidc-issuer: "https://token.actions.githubusercontent.com"
    identity-regexp: "^https://github.com/myorg/.*$"

CLI Commands

# Sign an image after build/push
sc image sign --image docker.example.com/myapp:v1.0.0

# Sign with explicit key
sc image sign --image docker.example.com/myapp:v1.0.0 --key cosign.key

# Verify signature
sc image verify --image docker.example.com/myapp:v1.0.0

# Sign all images in a stack
sc stack sign -s mystack -e production

Implementation Notes

• Recommended Tool: Cosign v3.0.2+
• Keyless Signing: Use Sigstore/Fulcio for OIDC-based keyless signing
• Transparency Log: Signatures recorded in Rekor for public auditability
• CI/CD Integration: Requires id-token: write permission in GitHub Actions

2. SBOM Generation

Configuration

sbom:
  enabled: true                          # Enable/disable SBOM generation (default: false)
  format: cyclonedx-json                 # cyclonedx-json, spdx-json, syft-json
  generator: syft                        # syft (recommended), trivy, or custom

  attach:
    enabled: true                        # Attach SBOM as in-toto attestation to image
    sign: true                           # Sign the SBOM attestation

  output:
    local: ./sbom/                       # Save SBOM locally
    registry: true                       # Push to registry as attestation

CLI Commands

# Generate SBOM for an image
sc sbom generate --image docker.example.com/myapp:v1.0.0 --format cyclonedx-json

# Generate and attach SBOM as attestation
sc sbom attach --image docker.example.com/myapp:v1.0.0 --sbom sbom.json

# Generate SBOM for all images in a stack
sc stack sbom -s mystack -e production --output ./sboms/

# Verify SBOM attestation
sc sbom verify --image docker.example.com/myapp:v1.0.0

Implementation Notes

• Recommended Tool: Syft v1.41.0+
• Component Coverage: Syft detects 6,000+ components vs 2,000 for alternatives
• Format: CycloneDX JSON recommended for broad tooling compatibility
• Attestation Format: in-toto predicate type for OCI registry storage

3. SLSA Provenance Attestation

Configuration

provenance:
  enabled: true                          # Enable/disable provenance (default: false)
  version: "1.0"                         # SLSA provenance version

  builder:
    id: "https://github.com/myorg/myrepo"

  metadata:
    include-env: false                   # Include (sanitized) environment variables
    include-materials: true              # Include source materials (git refs)

CLI Commands

# Generate and attach SLSA provenance
sc provenance attach --image docker.example.com/myapp:v1.0.0 \
  --source-repo github.com/myorg/myrepo \
  --git-sha abc123 \
  --workflow-name "Release"

# Verify provenance
sc provenance verify --image docker.example.com/myapp:v1.0.0

Implementation Notes

• SLSA Version: v1.0 provenance format
• Builder Identity: Derived from CI/CD environment (GitHub Actions, GitLab CI, etc.)
• Non-falsifiable: Requires keyless signing with OIDC identity

4. Vulnerability Scanning Integration

Configuration

security:
  scan:
    enabled: true                        # Enable vulnerability scanning (default: false)
    tools:
      - name: grype                      # Primary scanner
        required: true                   # Fail if scanner fails
        fail-on: critical                # Fail on critical vulnerabilities (optional)
      - name: trivy                      # Validation scanner (defense in depth)
        required: true

    upload:
      defectdojo:
        enabled: true
        url: https://defectdojo.example.com
        api-key: ${secret:defectdojo-api-key}

CLI Commands

# Scan an image
sc image scan --image docker.example.com/myapp:v1.0.0

# Scan with specific tools
sc image scan --image docker.example.com/myapp:v1.0.0 --tools grype,trivy

# Scan all images in a stack
sc stack scan -s mystack -e production

---

Integrated Workflow Example

Combined Release Workflow

# sc stack configuration for production releases
release:
  signing:
    enabled: true
    keyless: true

  sbom:
    enabled: true
    format: cyclonedx-json
    attach: true

  provenance:
    enabled: true

  security:
    scan:
      enabled: true
      tools:
        - name: grype
          required: true
        - name: trivy
          required: true

CLI Usage

# Full release with signing, SBOM, provenance, and scanning
sc release create -s mystack -e production --version 2026.1.7

# This would automatically:
# 1. Build and push images
# 2. Generate SBOM for each image (Syft)
# 3. Scan images for vulnerabilities (Grype + Trivy)
# 4. Sign images with Cosign (keyless)
# 5. Attach SBOM as signed attestation
# 6. Attach SLSA provenance as signed attestation
# 7. Upload scan results to DefectDojo
# 8. Create Git tag and release notes

---

NIST SP 800-218 Compliance Mapping

SSDF Practice	Requirement	Simple Container Feature
PW.1.3	Review code before deploying	Pre-deploy vulnerability scanning
PS.1.1	Generate and maintain SBOMs	sc sbom generate
PS.3.1	Archive and protect build artifacts	Signed images + Rekor transparency log
PS.3.2	Verify integrity before use	sc image verify, sc sbom verify
RV.1.1	Identify known vulnerabilities	sc image scan with dual-toolchain
RV.1.3	Continuously monitor for vulnerabilities	DefectDojo integration

---

SLSA Compliance Mapping

SLSA Level	Requirement	Simple Container Feature
Level 1	Build process fully scripted	sc CLI automation
Level 2	Version control + signed provenance	Git integration + sc provenance attach
Level 3	Hardened build platform + non-falsifiable provenance	Keyless signing via OIDC

---

Implementation Recommendations

Tool Versions (Tested)

Tool	Version	Purpose
Cosign	3.0.2	Image signing (via cosign-installer v4.0.0)
Syft	1.41.0	SBOM generation (6,265 components)
Grype	0.106.0	Primary vulnerability scanning
Trivy	0.68.2	Validation scanning (defense in depth)

Performance Considerations

Based on our production experience with 9 services:

Operation	Sequential	Parallel	Recommendation
SBOM Generation	31s/image	31s total	Parallelize per-service
Signing	40s/image	40s total	Parallelize with 0.5s stagger (OIDC rate limits)
Scanning	89s/image	58s/image	Run Grype + Trivy in parallel

Error Handling

• Retry Logic: Implement exponential backoff for transient failures (network, registry)
• Required vs Optional: Allow configuration of which steps are required vs best-effort
• Fail-Fast: Option to stop on first failure or continue and report all failures

---

Alternative Approaches Considered

Option A: Shell Script Wrapper (Current Approach)

We currently implement signing in a 2,400-line bash script (release-images.sh). This works but has drawbacks:

• Complex maintenance
• Limited reusability across projects
• No standardized configuration

Option B: Native Simple Container Integration (Requested)

Integrated into sc CLI with YAML configuration:

• Consistent user experience
• Declarative configuration
• Reusable across all projects
• Maintained by Simple Container team

Option C: Separate Plugin

A plugin architecture could work but adds complexity for a security-critical feature.

Recommendation: Option B - Native integration provides the best security and user experience.

---

Questions for Simple Container Team

1. Configuration Location: Should signing config be per-stack, per-environment, or global?
2. Secrets Management: How should signing keys/credentials be securely stored?
3. CI/CD Detection: Can sc auto-detect CI environment for OIDC configuration?
4. Registry Support: Which registries should be tested (ECR, Harbor, DockerHub, etc.)?
5. Timeline: What is the feasibility for inclusion in the next major release?

---

Reference Implementation

We have a working implementation in our release-images.sh script that demonstrates:

• Parallel signing of 9 services (80% faster than sequential)
• Dual-toolchain scanning (Syft+Grype + Trivy)
• SBOM generation and attestation
• SLSA provenance attachment
• AWS Marketplace ECR publishing with signing
• Helm chart signing

We are happy to share this implementation as a reference and collaborate on the Simple Container integration.

---

Appendix: NIST SP 800-218 SSDF Reference

NIST Special Publication 800-218 - Secure Software Development Framework (SSDF)

Key practices addressed by this feature request:

• PS (Protect Software): Protect all forms of code from unauthorized access and tampering
• PW (Produce Well-Secured Software): Produce well-secured software with minimal security vulnerabilities
• RV (Respond to Vulnerabilities): Identify residual vulnerabilities and respond appropriately

Full document: https://csrc.nist.gov/publications/detail/sp/800-218/final

FYI @Cre-eD

[simple-container-forge]

✅ Workflow Completed Successfully!

Great news! The Simple Forge has successfully processed your request.

📋 Job Details:

• Job ID: 1b91d060-4b82-4dc1-ba6d-08f62442f13b
• Job URL: https://forge.simple-container.com/jobs/1b91d060-4b82-4dc1-ba6d-08f62442f13b
• Branch: simple-forge/issue-93-feature-request-container-imag-t9y45l
• Workflow: View Results
• Completed: 2026-02-04 17:58:36 UTC

📝 Execution Summary:
I've processed the issue and made the following changes:

I'll analyze the repository structure and the issue #93 to understand the requirements for Container Image Signing, SBOM, and Attestation features.

Let me start by exploring the codebase to understand the current architecture and then create comprehensive product requirements documentation.

Let me explore the existing codebase structure to understand the current architecture and how images are built and managed.

Now I'll create the todo list and examine example configuration files to understand how the system currently works:

Now I'll create the product requirements documentation directory and files:

Now I'll create the comprehensive product requirements documentation:

Now I'll update the todo list and create the handoff JSON:

Now let me verify all the files were created correctly and then generate the final handoff JSON:

Perfect! All documentation files have been created. Now let me mark the final todo as complete and prepare my response with the handoff JSON:

Product Requirements Analysis Complete

I've successfully analyzed issue #93 and created comprehensive product requirements documentation for the Container Image Security features (signing, SBOM, and attestation).

What I Created

I've created three detailed documentation files under docs/product-manager/container-security/:

1. requirements.md (24KB) - Comprehensive product requirements including:

• Executive summary and business context
• Detailed functional requirements (FR-1 through FR-10)
• Non-functional requirements (performance, security, compatibility)
• User personas and use cases
• NIST SP 800-218 and SLSA compliance mapping
• Phasing strategy (MVP → Phase 2 → Phase 3)

2. acceptance-criteria.md (16KB) - Detailed acceptance criteria including:

• Test cases for all features
• Verification checklists
• Definition of done
• Test environments
• Sign-off requirements

3. task-breakdown.md (29KB) - Implementation task breakdown including:

• 15 detailed tasks organized into 5 phases
• Code examples and technical specifications
• Effort estimates (34-44 days total)
• Dependencies and risk mitigations
• Success metrics

Key Design Decisions

Based on my analysis of the Simple Container codebase and the custom instructions to keep scope minimal:

1. Opt-in by Design: All security features are optional via YAML configuration - no breaking changes
2. External Tools: Leverage Cosign (v3.0.2+) and Syft (v1.41.0+) rather than reimplementing
3. Backward Compatible: New configuration fields added to existing StackConfigCompose and StackConfigSingleImage structs
4. Minimal MVP: Focus on keyless signing + SBOM for first release (Phase 1)
5. Standard Formats: CycloneDX JSON for SBOM, SLSA v1.0 for provenance

Architecture Highlights

The solution extends the existing architecture by:

• Adding new pkg/security/ package with subpackages for signing, SBOM, and provenance
• Integrating into existing build/deploy workflow in pkg/clouds/compose/
• Adding new CLI commands under sc image, sc sbom, and sc provenance
• Supporting both automatic (config-driven) and manual (CLI) operations

---

[Content truncated - full details available in workflow logs]

🎉 Next Steps:

• Review the changes in the branch simple-forge/issue-93-feature-request-container-imag-t9y45l
• Test the implementation
• Create a pull request when ready

Feel free to ask for any modifications or improvements!

[simple-container-forge]

❌ Workflow Failed

Unfortunately, there was an issue processing your request:

📋 Job Details:

• Job ID: 0d2698d2-322e-4cd5-b9e5-b54f2d424709
• Job URL: https://forge.simple-container.com/jobs/0d2698d2-322e-4cd5-b9e5-b54f2d424709
• Branch: simple-forge/issue-93-feature-request-container-imag-t9y597
• Workflow: View Failed Run

🚨 Error Details:
Workflow failed with conclusion: cancelled
🔧 Troubleshooting:

• Please check the workflow logs for detailed error information
• If the issue persists, try commenting again or contact support

📝 Next Steps:

• Review the workflow logs for detailed information
• Try commenting again if this was a temporary issue
• Contact support if the problem continues

[simple-container-forge]

✅ Workflow Completed Successfully!

Great news! The Simple Forge has successfully processed your request.

📋 Job Details:

• Job ID: d878eaa7-3f6c-4e1f-bb70-f39f339e1787
• Job URL: https://forge.simple-container.com/jobs/d878eaa7-3f6c-4e1f-bb70-f39f339e1787
• Branch: simple-forge/issue-93-feature-request-container-imag-t9y5ne
• Workflow: View Results
• Completed: 2026-02-04 18:31:36 UTC

📝 Execution Summary:
I've processed the issue and made the following changes:

I'll analyze the issue and create the necessary product requirements documentation. Let me start by understanding the context.

Now let me explore the existing codebase structure to understand how Simple Container is currently implemented:

Excellent! Now let me check if there's existing documentation structure for product manager docs:

Now let me create a comprehensive product requirements document. I'll create the directory structure and documentation:

Now let me create additional supporting documents for the feature breakdown and acceptance criteria:

Now let me create a technical constraints and dependencies document:

Now let me verify the files were created successfully:

Perfect! Now let me create one more document - a summary README for the product manager documentation:

Perfect! Now let me verify all files are created and prepare the handoff JSON:

Excellent! Now let me create a final summary and provide the handoff JSON. Let me verify my work:

Perfect! All documentation has been created successfully. Now let me provide the comprehensive response with the handoff JSON:

---

✅ Product Requirements Analysis Complete

I have successfully analyzed Issue #93: Container Image Signing, SBOM, and Attestation and created comprehensive product requirements documentation.

📁 Documentation Created

I've created 4 comprehensive documents (2,210 total lines) in docs/product-manager/container-security/:

1. README.md (410 lines)

• Executive overview and quick reference
• Feature summary with priorities
• Success criteria and metrics
• Next steps for Architect role

2. requirements.md (603 lines)

• Detailed functional and non-functional requirements
• User stories with acceptance criteria
• Configuration schema definitions
• Risk analysis and mitigation strategies

3. feature-breakdown.md (586 lines)

• 5 discrete features with clear scope boundaries
• Implementation order and dependencies
• Testing strategy and rollout plan
• Future enhancement roadmap

4. constraints-and-dependencies.md (611 lines)

• Technical constraints (minimal changes, optional features)
• Performance requirements (< 10% overhead)
• External and internal dependencies
• Registry and tool compatibility matrices

---

🎯 Key Findings

Scope Decision: Based on my analysis of the existing codebase and the feature request, I'm recommending a SINGLE scope group with sequential workflow because:

1. All features are tightly coupled:

• SBOM signing depends on core signing infrastructure
• Attestation uses the same signing mechanism
• GitHub Actions integration requires all features working together

2. Shared integration points:

• All features hook into the same image build pipeline (BuildAndPushImage())
• All features use the same configuration schema (SecurityDescriptor)
• All features leverage the same secret management system

3. Logical progression:

• Phase 1: Core Signing (foundation)
• Phase 2: SBOM (builds on signing)
• Phase 3: Attestation (builds on signing)
• Phase 4: GitHub Actions (integrates all)
• Phase 5: CLI Commands (enhances usability)

4. Compliance as a whole:

• NIST SP 800-218, SLSA, and EO 14028 require the complete package
• Customers need signing + SBOM + attestation together for compliance
• Partial implementation provides limited value

---

🏗️ Architecture Insights

Minimal Integration Points Identified:

1. Image Build Pipeline (pkg/clouds/pulumi/docker/build_and_push.go)

• Add post-build hook for signing (~20 lines)
• Extend ImageOut struct with security metadata

2. Configuration Schema (pkg/api/server.go, pkg/api/client.go)

• Add SecurityDescriptor struct (additive change)
• No breaking changes to existing schemas

3. GitHub Actions Workflows (pkg/clouds/github/templates.go)

• Add conditional security steps (~15 lines)
• Auto-configure OIDC permissions

[Content truncated - full details available in workflow logs]

🎉 Next Steps:

• Review the changes in the branch simple-forge/issue-93-feature-request-container-imag-t9y5ne
• Test the implementation
• Create a pull request when ready

Feel free to ask for any modifications or improvements!