mirror of
https://github.com/SHOGGOTH-SECTOR/sica-fondt.git
synced 2026-08-01 16:40:24 +00:00
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
2.5 KiB
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 |