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
3.2 KiB
3.2 KiB
GHAS Implementation Workflows
Workflow 1: Organization-Wide Enablement
1. Audit current repository inventory
- List all repositories in the organization
- Identify languages and build systems in use
- Estimate active committer count for licensing
|
2. Pilot phase (2-4 weeks)
- Enable GHAS on 5-10 representative repositories
- Use default setup for initial scanning
- Collect baseline alert counts and false positive rates
|
3. Triage pilot results
- Review alerts by severity (Critical, High, Medium, Low)
- Dismiss confirmed false positives with documented reasons
- Create remediation issues for confirmed vulnerabilities
|
4. Tune configuration
- Adjust query suites based on false positive feedback
- Write custom queries for organization-specific patterns
- Configure alert dismissal policies
|
5. Broad rollout
- Enable default setup across remaining repositories
- Configure organization-level security configurations
- Set branch protection rules requiring code scanning checks
|
6. Continuous monitoring
- Review security overview dashboard weekly
- Track MTTR for code scanning alerts
- Report metrics to security leadership monthly
Workflow 2: Pull Request Security Gate
Developer pushes code to feature branch
|
PR is created targeting main
|
CodeQL analysis triggers automatically
|
Dependency review checks for vulnerable dependencies
|
Secret scanning checks for hardcoded credentials
|
Results posted as PR check and inline annotations
|
[Pass] All checks pass --> PR is eligible for merge
[Fail] Critical/High findings --> PR is blocked
|
Developer reviews findings and applies fixes
|
Re-push triggers re-analysis
|
Merge after all checks pass and reviewer approval
Workflow 3: Custom CodeQL Query Development
1. Identify recurring vulnerability pattern not caught by default queries
|
2. Set up CodeQL development environment
- Install CodeQL CLI
- Clone CodeQL standard library repository
- Create workspace with target codebase database
|
3. Author the query in QL language
- Define source, sink, and taint-tracking configuration
- Add metadata (@name, @description, @kind, @problem.severity, @security-severity, @precision, @id, @tags)
|
4. Test the query
- Create test cases with expected results
- Run `codeql test run` against test database
- Validate precision and recall
|
5. Package the query
- Create qlpack.yml with version and dependencies
- Publish to GitHub Container Registry or internal package registry
|
6. Deploy to scanning workflow
- Reference the query pack in codeql-action/init step
- Monitor results for the new query across repositories
Workflow 4: SARIF Integration with External Tools
External SAST/DAST tool runs scan
|
Tool outputs results in SARIF 2.1.0 format
|
GitHub Actions uploads SARIF via codeql-action/upload-sarif
|
Results appear in Security tab alongside CodeQL findings
|
Unified triage workflow across all scanning tools
|
Alert deduplication based on location and rule ID