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
1.6 KiB
1.6 KiB
Workflows - GCP Organization Policy Constraints
Implementation Workflow
1. Inventory Phase
├── List all existing organization policies
├── Identify current resource configurations
├── Map compliance requirements to constraints
└── Document exceptions needed per team/project
2. Design Phase
├── Select constraints for baseline enforcement
├── Define exception policies for specific folders/projects
├── Plan hierarchy (Org → Folder → Project overrides)
└── Document policy inheritance chain
3. Testing Phase
├── Deploy constraints in dry-run mode
├── Monitor violation logs for 2-4 weeks
├── Identify legitimate use cases requiring exceptions
└── Refine policies based on dry-run results
4. Enforcement Phase
├── Convert dry-run policies to enforced mode
├── Apply exceptions at appropriate hierarchy level
├── Communicate changes to engineering teams
└── Monitor for new violations
5. Ongoing Governance
├── Review policies quarterly
├── Audit exception requests
├── Update constraints for new GCP services
└── Integrate with change management process
Exception Management Workflow
1. Request → Developer requests exception for specific constraint
2. Review → Security team evaluates risk and business justification
3. Approve → Exception approved with scope (project/folder) and duration
4. Implement → Policy override applied at lowest necessary scope
5. Audit → Regular review of active exceptions
6. Expire → Time-bound exceptions automatically revert