mirror of
https://github.com/SHOGGOTH-SECTOR/sica-fondt.git
synced 2026-08-01 08:30:20 +00:00
24f816b6a3
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
85 lines
2.3 KiB
Markdown
85 lines
2.3 KiB
Markdown
# GitLab DevSecOps Pipeline Workflows
|
|
|
|
## Workflow 1: Merge Request Security Review
|
|
|
|
```
|
|
Developer creates merge request
|
|
|
|
|
Pipeline triggers security scanners in parallel:
|
|
[SAST] [Secret Detection] [Dependency Scanning] [License Scanning]
|
|
|
|
|
MR Security Widget displays results:
|
|
- New vulnerabilities introduced
|
|
- Existing vulnerabilities fixed
|
|
- Comparison with target branch
|
|
|
|
|
[No Critical/High] --> Reviewers can approve and merge
|
|
[Critical/High found] --> MR blocked by approval policy
|
|
|
|
|
Security team reviews findings
|
|
|
|
|
[Confirmed] --> Developer remediates and re-pushes
|
|
[False Positive] --> Dismissed with documented reason
|
|
|
|
|
All findings resolved --> MR eligible for merge
|
|
```
|
|
|
|
## Workflow 2: Container Image Security Gate
|
|
|
|
```
|
|
Docker image built in CI
|
|
|
|
|
Container scanning (Trivy) analyzes image layers
|
|
|
|
|
Findings categorized by severity
|
|
|
|
|
[Below threshold] --> Image pushed to registry with metadata
|
|
[Above threshold] --> Pipeline fails, image not pushed
|
|
|
|
|
Registry stores scan results as artifact
|
|
|
|
|
Deployment pulls only scanned/approved images
|
|
```
|
|
|
|
## Workflow 3: DAST Against Staging Environment
|
|
|
|
```
|
|
Application deployed to staging
|
|
|
|
|
DAST browser scan initiated against staging URL
|
|
|
|
|
Authenticated scan crawls application pages
|
|
|
|
|
Active testing for XSS, SQLi, CSRF, etc.
|
|
|
|
|
Results added to vulnerability report
|
|
|
|
|
[Pass] --> Manual deploy-to-production gate enabled
|
|
[Fail on critical] --> Staging deployment rolled back
|
|
|
|
|
Production deploy requires manual approval
|
|
```
|
|
|
|
## Workflow 4: Vulnerability Lifecycle Management
|
|
|
|
```
|
|
Scanner detects vulnerability
|
|
|
|
|
Status: "Detected" in vulnerability report
|
|
|
|
|
Security analyst triages finding
|
|
|
|
|
[Confirmed vulnerability] [False positive]
|
|
| |
|
|
Status: "Confirmed" Status: "Dismissed"
|
|
Issue created automatically Reason documented
|
|
|
|
|
Developer assigned fix
|
|
|
|
|
Fix merged, scanner re-runs
|
|
|
|
|
Vulnerability no longer detected
|
|
|
|
|
Status: "Resolved"
|
|
```
|