Initial commit - 611 cybersecurity skills across all subdomains

skills/implementing-supply-chain-security-with-in-toto/references/standards.md

@@ -0,0 +1,51 @@
+# Standards and References - Supply Chain Security with in-toto
+
+## Industry Standards
+
+### SLSA (Supply chain Levels for Software Artifacts)
+- in-toto provides the attestation framework that SLSA builds upon
+- SLSA provenance attestations use in-toto attestation format
+- Graduated to v1.0 specification with clear level requirements
+
+### NIST SSDF (Secure Software Development Framework) SP 800-218
+- PO.1.1: Define and document security requirements for software
+- PS.1.1: Verify third-party software components
+- PW.4.1: Review and analyze source code for security vulnerabilities
+
+### NIST SP 800-204D: Strategies for Securing the Software Supply Chain
+- Section 4: Build system integrity verification
+- Section 5: Attestation-based supply chain verification
+- Recommends cryptographic provenance tracking
+
+### Executive Order 14028 (Improving the Nation's Cybersecurity)
+- Requires SBOM generation for software sold to federal government
+- Mandates supply chain security for critical software
+- in-toto attestations satisfy provenance requirements
+
+## Compliance Mapping
+
+| Requirement | Framework | in-toto Capability |
+|-------------|-----------|-------------------|
+| Build provenance | SLSA L2+ | Signed link metadata per build step |
+| Artifact integrity | NIST 800-204D | SHA-256 hash chaining between steps |
+| Authorized builders | SLSA L3+ | Functionary key verification |
+| SBOM generation | EO 14028 | Inspection step for SBOM validation |
+| Code review | SLSA L4 | Threshold signing with multiple reviewers |
+| Tamper detection | PCI DSS 6.5 | End-to-end verification before deployment |
+
+## Ecosystem Integration
+
+### Sigstore
+- Keyless signing via Fulcio certificate authority
+- Transparency log via Rekor for attestation persistence
+- Cosign for container image signing and verification
+
+### Witness / Archivista
+- Witness: in-toto implementation focused on cloud-native CI/CD
+- Archivista: Attestation storage and retrieval service
+- Both used by SolarWinds for supply chain integrity post-breach
+
+### OpenVEX
+- Vulnerability Exploitability eXchange format
+- Complements in-toto attestations with vulnerability status
+- Allows marking CVEs as "not affected" for specific builds

skills/implementing-supply-chain-security-with-in-toto/references/workflows.md

@@ -0,0 +1,77 @@
+# Workflows - Supply Chain Security with in-toto
+
+## Implementation Workflow
+
+### Phase 1: Layout Design
+1. Map your CI/CD pipeline steps (source, build, test, scan, package, push)
+2. Identify functionaries for each step (CI runner, scanner, reviewer)
+3. Define artifact flow between steps (what inputs/outputs)
+4. Generate signing keys for each functionary
+5. Create and sign the supply chain layout
+
+### Phase 2: Pipeline Integration
+1. Wrap each CI/CD step with `in-toto-run` to generate link metadata
+2. Configure key management (Vault, KMS, or Sigstore keyless)
+3. Store link metadata alongside build artifacts
+4. Verify supply chain at end of pipeline before push to registry
+5. Attach attestations to container images via cosign
+
+### Phase 3: Deployment Verification
+1. Deploy admission webhook for in-toto verification
+2. Configure policy engine to require valid attestations
+3. Test with known-good and known-bad attestation chains
+4. Enable enforcement mode to block unverified images
+5. Monitor verification failures and alert on anomalies
+
+## CI/CD Pipeline Integration
+
+### GitHub Actions Example
+```yaml
+jobs:
+  build:
+    steps:
+      - uses: actions/checkout@v4
+      - name: Record checkout step
+        run: |
+          in-toto-run --step-name checkout \
+            --key ${{ secrets.BUILDER_KEY }} \
+            --products Dockerfile src/* \
+            -- echo "checkout complete"
+      - name: Build and record
+        run: |
+          in-toto-run --step-name build \
+            --key ${{ secrets.BUILDER_KEY }} \
+            --materials Dockerfile src/* \
+            --products image-digest.txt \
+            -- docker build -t app:${{ github.sha }} .
+      - name: Scan and record
+        run: |
+          in-toto-run --step-name scan \
+            --key ${{ secrets.SCANNER_KEY }} \
+            --materials image-digest.txt \
+            --products vuln-report.json sbom.json \
+            -- trivy image app:${{ github.sha }}
+      - name: Verify chain
+        run: |
+          in-toto-verify --layout root.layout \
+            --layout-key keys/owner.pub
+```
+
+## Key Rotation Workflow
+
+1. Generate new key pair for the functionary
+2. Update the supply chain layout with new public key
+3. Re-sign the layout with the owner key
+4. Distribute new private key to the functionary (via secrets manager)
+5. Revoke the old key after transition period
+6. Verify builds use new key going forward
+
+## Incident Response Workflow
+
+### Supply Chain Compromise Detected
+1. Identify which step's attestation is invalid or missing
+2. Check if functionary key was compromised
+3. Review link metadata for the affected step
+4. Compare artifact hashes against known-good builds
+5. If compromise confirmed: revoke affected keys, rebuild from verified source
+6. Update layout to add additional verification requirements