Claude 24f816b6a3
Consolidate 22 sibling repos into layered organism structure
Place useful parts of the surrounding repos into sica-fondt by layer, per the
body model (Ada = membrane; brain/endocrine/capabilities/knowledge non-Ada):

- brain/        LLM reasoning + providers (dapr, hermes, MoMoA)
- capabilities/ REPRAG sidecars: hermes tools/skills, dapr tools, parallel
                dispatch, A51 channels, and the OSINT cluster
- knowledge/    LORAG corpus: 754 cyber-skills, agency personas, secure-coding,
                MITRE ATT&CK data
- reference/    defensive threat-reference (C3, shhbruh doc) + AdaYaml parser

License handling: AGPL sources (worldosint, advanced_evolution, mercury,
Reticulum) and GPL DeTTECT are SPEC-only clean-room/port descriptions — no
copyleft code copied. MIT/Apache/data parts copied as working trees.

Safety: shhbruh escape/persistence material and C3 covert-C2 kept as reference
only, not wired into the running organism. See CONSOLIDATION.md.

https://claude.ai/code/session_01UehUqEXXJJCsHoA4voCU5c
2026-06-10 06:53:01 +00:00

2.5 KiB

Standards Reference - Docker Image Scanning with Trivy

NIST SP 800-190 - Application Container Security Guide

Relevant Controls

  • Image Vulnerability Management: Organizations should maintain a pipeline for scanning and remediating container image vulnerabilities
  • Image Provenance: Use content trust and signing to verify image source and integrity
  • SBOM Generation: Produce Software Bill of Materials for all container images

CIS Docker Benchmark v1.8.0

Section 4: Container Images and Build File

  • 4.4: Ensure images are scanned and rebuilt to include security patches
  • 4.5: Ensure Content trust for Docker is Enabled
  • 4.8: Ensure setuid and setgid permissions are removed

NIST SSDF (Secure Software Development Framework)

PW.4 - Reuse Existing, Well-Secured Software

  • PW.4.1: Verify third-party software components have no known vulnerabilities
  • PW.4.4: Verify software components are obtained from trusted sources

RV.1 - Identify and Confirm Vulnerabilities

  • RV.1.1: Gather information from vulnerability notifications
  • RV.1.2: Review, analyze, and/or test code to identify vulnerabilities

OWASP Container Security Verification Standard

V2: Image Security

  • 2.1: Verify images are scanned for known vulnerabilities before deployment
  • 2.2: Verify base images are from trusted sources
  • 2.3: Verify images do not contain embedded secrets
  • 2.4: Verify unnecessary packages are removed from images
  • 2.5: Verify images use minimal base (distroless/Alpine)

Executive Order 14028 - Improving the Nation's Cybersecurity

SBOM Requirements

  • Software producers must provide SBOMs for federal software
  • SBOMs must follow NTIA minimum elements
  • Supported formats: SPDX, CycloneDX
  • Trivy supports both SPDX and CycloneDX SBOM generation

Trivy Vulnerability Scoring

CVSS v3.1 Severity Mapping

Score Range Severity Trivy Flag
9.0 - 10.0 CRITICAL --severity CRITICAL
7.0 - 8.9 HIGH --severity HIGH
4.0 - 6.9 MEDIUM --severity MEDIUM
0.1 - 3.9 LOW --severity LOW
N/A UNKNOWN --severity UNKNOWN

Vulnerability Data Sources

Source Coverage
NVD All CVEs
GHSA GitHub ecosystem packages
Red Hat OVAL RHEL, CentOS
Debian Security Tracker Debian
Ubuntu CVE Tracker Ubuntu
Alpine SecDB Alpine Linux
Amazon ALAS Amazon Linux
SUSE OVAL SUSE/openSUSE
Wolfi SecDB Wolfi/Chainguard