sinapse-ai 9.2.0 → 9.4.0

package/squads/squad-cybersecurity/knowledge-base/penetration-testing-methodology.md

@@ -0,0 +1,350 @@
+# Penetration Testing Methodology Reference
+
+## Purpose
+
+Complete methodology reference for authorized penetration testing — PTES phases, OWASP Testing Guide, tool selection, and reporting standards. Used exclusively by Breach (penetration-tester). All operations require verified written authorization.
+
+**ETHICAL GATE:** Every engagement starts with written authorization, defined scope, and rules of engagement. No exceptions.
+
+---
+
+## PTES: Penetration Testing Execution Standard
+
+The PTES defines 7 phases for a complete penetration test engagement.
+
+### Phase 1: Pre-Engagement
+
+Define the scope, rules, and legal authorization before any technical work begins.
+
+**Required artifacts before proceeding:**
+- Written authorization (signed scope of work or letter of authorization)
+- Defined in-scope assets (IP ranges, domains, applications, APIs)
+- Out-of-scope assets explicitly listed
+- Rules of engagement (testing windows, contacts, escalation path)
+- Emergency stop procedure (who to call if critical infrastructure affected)
+- Data handling agreement (how findings are stored and transmitted)
+
+**Authorization verification checklist:**
+```
+[ ] Written authorization received and on file
+[ ] Scope document signed by authorized representative
+[ ] Out-of-scope assets documented
+[ ] Testing windows agreed upon
+[ ] Emergency contact available
+[ ] Findings handling agreed (encryption, retention)
+[ ] Legal jurisdiction confirmed
+```
+
+### Phase 2: Intelligence Gathering (Reconnaissance)
+
+Collect information about the target using only authorized, passive techniques unless active recon is explicitly permitted.
+
+**Passive recon (always allowed within scope):**
+```bash
+# DNS enumeration
+dig +short example.com any
+dnsx -d example.com -a -aaaa -mx -ns -cname -txt
+
+# Subdomain discovery (passive, no direct contact)
+subfinder -d example.com -silent
+
+# WHOIS and registration data
+whois example.com
+
+# Certificate transparency logs (public data)
+curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value'
+
+# Google dorking — public info indexed by search engines
+site:example.com filetype:pdf
+site:example.com inurl:admin
+```
+
+**Active recon (requires explicit authorization):**
+```bash
+# Port scanning — only against authorized IPs
+nmap -sV -sC -p 1-65535 --open -T4 target.example.com
+
+# Service version detection
+nmap -sV -p 80,443,8080,8443 target.example.com
+
+# Web technology fingerprinting
+whatweb target.example.com
+```
+
+### Phase 3: Threat Modeling
+
+Map identified attack surface to threat scenarios:
+- Document open ports and services
+- Map application technologies (CMS, frameworks, libraries)
+- Identify authentication mechanisms
+- Note third-party integrations and external dependencies
+- Cross-reference CVEs for identified versions
+
+### Phase 4: Vulnerability Analysis
+
+Systematically identify vulnerabilities using automated tools and manual techniques.
+
+**Automated scanning:**
+```bash
+# Web application scanning (DAST)
+# OWASP ZAP — automated scan
+zap-cli --zap-url http://localhost:8080 quick-scan --self-contained --spider \
+  --ajax-spider -r --output-format json http://target.example.com
+
+# Nuclei — template-based vulnerability scanner
+nuclei -u https://target.example.com -t /opt/nuclei-templates/ -severity critical,high,medium
+
+# SSL/TLS configuration
+sslyze --regular target.example.com:443
+
+# Directory and path discovery
+feroxbuster -u https://target.example.com -w /usr/share/wordlists/dirb/common.txt
+```
+
+**Manual techniques:**
+- Review all input fields for injection opportunities
+- Test authentication flows manually
+- Examine session management (cookie attributes, token entropy)
+- Check access control by testing role boundaries
+- Review security headers in all responses
+
+### Phase 5: Exploitation
+
+Attempt to confirm vulnerabilities by safely exploiting them within scope.
+
+**Exploitation principles:**
+- Confirm vulnerability, do not cause harm
+- Avoid denial of service or data destruction
+- Document every action with timestamps
+- Stop immediately if you exceed scope or find unexpected sensitive data
+- Escalate to client immediately if you find evidence of a pre-existing breach
+
+**Burp Suite Professional workflow:**
+```
+1. Configure browser proxy → Burp Proxy (127.0.0.1:8080)
+2. Spider/crawl target to map attack surface
+3. Run active scanner against scope
+4. Review scanner findings in Burp Dashboard
+5. Manual exploitation via Burp Repeater
+6. Track all requests in Burp Project
+```
+
+### Phase 6: Post-Exploitation
+
+Assess the real-world impact of confirmed vulnerabilities:
+- What data is accessible?
+- Can the compromise spread to other systems (lateral movement risk)?
+- What is the business impact of the vulnerability?
+- Can the attacker persist (would they establish persistence in a real attack)?
+
+**Document for report:**
+- Screenshot of successful exploitation
+- Data accessed (record existence, not full contents)
+- Privilege level achieved
+- Potential blast radius
+
+### Phase 7: Reporting
+
+Produce actionable, audience-appropriate findings.
+
+---
+
+## Reporting Standards
+
+### Finding Severity Classification
+
+Use CVSS v3.1 for consistent scoring:
+
+| Severity | CVSS Score | Remediation SLA | Definition |
+|----------|-----------|----------------|------------|
+| **Critical** | 9.0–10.0 | 24–48 hours | Remote code execution, unauthenticated data breach |
+| **High** | 7.0–8.9 | 7 days | Auth bypass, significant data exposure |
+| **Medium** | 4.0–6.9 | 30 days | Requires auth, limited impact |
+| **Low** | 0.1–3.9 | 90 days | Defense-in-depth issues, information disclosure |
+| **Informational** | 0.0 | Next cycle | Best practice improvements |
+
+### Finding Template
+
+Every finding should contain:
+```
+Title: [Concise description]
+Severity: [Critical/High/Medium/Low/Informational]
+CVSS Score: [X.X]
+CVE Reference: [If applicable]
+
+Description:
+[What the vulnerability is and why it matters]
+
+Affected Systems:
+[Specific URLs, endpoints, or components]
+
+Evidence:
+[Screenshots, request/response, proof of concept]
+
+Impact:
+[Business impact if exploited by a real attacker]
+
+Remediation:
+[Specific, actionable fix instructions]
+
+References:
+[OWASP, CVE, vendor docs]
+```
+
+---
+
+## Tool Reference
+
+### Core Toolchain
+
+| Tool | Category | License | Primary Use |
+|------|----------|---------|-------------|
+| **Burp Suite Pro** | DAST | Commercial | Web app testing, manual exploitation |
+| **OWASP ZAP** | DAST | Free/Open Source | CI/CD automation, budget-constrained tests |
+| **Nmap** | Network | Free/Open Source | Port scanning, service discovery |
+| **Metasploit** | Exploitation | Free/Commercial | Exploit framework, post-exploitation |
+| **Nuclei** | Scanner | Free/Open Source | Template-based vulnerability scanning |
+| **Semgrep** | SAST | Free/Commercial | Static code analysis |
+| **Snyk** | SCA | Free/Commercial | Dependency vulnerability scanning |
+| **SQLmap** | Injection | Free/Open Source | Automated SQL injection |
+| **Hydra / Medusa** | Auth | Free/Open Source | Brute force (authorized tests only) |
+| **Gobuster / Feroxbuster** | Recon | Free/Open Source | Directory and file discovery |
+| **SSLyze** | TLS | Free/Open Source | SSL/TLS configuration testing |
+
+### For Beginners — Progressive Stack
+
+**Phase 1 (Learning):**
+1. OWASP ZAP in automatic mode — spider + active scan
+2. `npm audit` for dependency vulnerabilities
+3. Semgrep for SAST basics
+
+**Phase 2 (Intermediate):**
+4. Burp Suite Community (learn the proxy)
+5. Nmap for infrastructure assessment
+6. Nuclei with community templates
+
+**Phase 3 (Professional):**
+7. Burp Suite Professional (license)
+8. Custom Nuclei templates for client-specific checks
+9. Manual exploitation techniques
+
+---
+
+## OWASP Testing Guide Categories (v4.2)
+
+The OWASP Testing Guide (OTG) provides the most comprehensive methodology for web application testing:
+
+| Category | Key Tests |
+|----------|----------|
+| **OTG-INFO** Information Gathering | Fingerprinting, search engine discovery, web server analysis |
+| **OTG-CONFIG** Configuration | Network/infrastructure config, application platform, HTTP methods |
+| **OTG-IDENT** Identity Management | User registration, account provisioning, username policy |
+| **OTG-AUTHN** Authentication | Credentials over encrypted channel, default credentials, brute force |
+| **OTG-AUTHZ** Authorization | Directory traversal, privilege escalation, IDOR, OAuth testing |
+| **OTG-SESS** Session Management | Cookie attributes, session fixation, CSRF, logout |
+| **OTG-INPVAL** Input Validation | XSS, SQL injection, HTTP injection, XML injection, code injection |
+| **OTG-ERR** Error Handling | Error codes, stack traces |
+| **OTG-CRYPST** Cryptography | Weak SSL, padding oracle, sensitive data in transit |
+| **OTG-BUSLOGIC** Business Logic | Data validation, process flow, file upload |
+| **OTG-CLIENT** Client-Side Testing | DOM-based XSS, PostMessage, clickjacking |
+
+---
+
+## API Security Testing
+
+### REST API Test Checklist
+
+```
+Authentication
+[ ] Endpoints accessible without auth tokens
+[ ] Auth tokens transmitted securely (HTTPS, not URL params)
+[ ] Token expiration enforced
+[ ] Token revocation works (logout invalidates token)
+
+Authorization
+[ ] BOLA: can user A access user B's resources by changing IDs?
+[ ] BFLA: can user access admin functions without admin role?
+[ ] Mass assignment: does API accept undocumented parameters that affect auth?
+
+Input Validation
+[ ] Injection in all string parameters (SQL, NoSQL, command)
+[ ] Path traversal in file-related endpoints
+[ ] XML/JSON deserialization risks
+
+Business Logic
+[ ] Rate limiting on resource-intensive endpoints
+[ ] Can users exceed intended limits (purchase 0-price items, negative quantities)?
+[ ] Workflow enforcement (can user skip required steps?)
+
+Infrastructure
+[ ] Security headers present
+[ ] API version disclosure (avoid version in response if possible)
+[ ] Error messages don't expose internal details
+```
+
+### GraphQL-Specific Tests
+
+```bash
+# Introspection (should be disabled in production)
+curl -X POST https://api.target.com/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{__schema{types{name}}}"}'
+
+# Batch query attack (no rate limiting on batches)
+# [{"query":"query1"},{"query":"query2"},...] x100
+
+# Field suggestion (typos reveal valid field names)
+# GraphQL returns "Did you mean X?" — information disclosure
+```
+
+---
+
+## Cloud Environment Testing
+
+### AWS Security Assessment
+
+Key areas to test with explicit authorization:
+
+```bash
+# IAM privilege analysis (with legitimate credentials)
+# Check for privilege escalation paths
+python3 enumerate_iam.py
+
+# S3 bucket exposure (requires authorization)
+aws s3 ls s3://bucket-name --no-sign-request  # Check for public access
+
+# EC2 metadata service exposure
+# Test if SSRF can reach: http://169.254.169.254/latest/meta-data/
+
+# Lambda function permissions
+aws lambda get-policy --function-name my-function
+
+# Check for IMDSv1 (should be disabled — SSRF risk)
+aws ec2 describe-instances --query "Reservations[].Instances[].MetadataOptions"
+```
+
+### Kubernetes Security Assessment
+
+```bash
+# RBAC analysis
+kubectl auth can-i --list --as=system:serviceaccount:default:myapp
+
+# Check for privileged pods
+kubectl get pods -A -o json | jq '.items[].spec.containers[].securityContext'
+
+# Network policy coverage
+kubectl get networkpolicies -A
+
+# Check for secrets in env vars (common misconfiguration)
+kubectl get pods -A -o json | jq '.items[].spec.containers[].env'
+```
+
+---
+
+## Sources
+
+- PTES: http://www.pentest-standard.org/
+- OWASP Testing Guide v4.2: https://owasp.org/www-project-web-security-testing-guide/
+- OWASP API Security Testing Guide: https://owasp.org/www-project-api-security/
+- OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/
+- HackTricks: https://book.hacktricks.xyz/ (for methodology reference — authorized tests only)

package/squads/squad-cybersecurity/knowledge-base/supply-chain-security.md

@@ -0,0 +1,311 @@
+# Supply Chain Security Reference
+
+## Purpose
+
+Reference for software supply chain security — SLSA framework, Sigstore signing, SBOM generation, dependency scanning, and real-world attack context. Used by Breach (penetration-tester) and Govern (compliance-officer).
+
+---
+
+## The Post-SolarWinds Landscape
+
+The period after SolarWinds (December 2020) and Log4Shell (December 2021) transformed supply chain security from a theoretical concern to a regulatory requirement.
+
+**Key regulatory drivers:**
+- **US Executive Order 14028** (May 2021) — mandated SBOM requirements and Zero Trust standards for software sold to the US federal government
+- **EO 14144** (January 2025) — added detailed requirements
+- **EO 14306** (June 2025) — rescinded parts of 14144 but maintained NIST SP 800-218 (SSDF) guidance
+- The private market adopted these standards independently of federal timelines
+
+---
+
+## Real-World Attacks (2025-2026)
+
+| Date | Target | Weekly Downloads | Attack Vector | Impact |
+|------|--------|-----------------|---------------|--------|
+| Dec 2021 | Log4j (Log4Shell) | Billions | RCE vulnerability in ubiquitous library | Most critical vuln of the decade |
+| Sep 2025 | debug, chalk + 16 npm packages | 2.6 billion combined | Maintainer phishing, credential theft | Malicious code injected into popular packages |
+| Mar 2026 | Axios | 100M+ | North Korean APT credential theft | Supply chain code execution |
+
+**Log4Shell lesson:** When Log4j was disclosed, most organizations did not know if they used it or where. SBOMs answer that question instantly.
+
+---
+
+## SBOM: Software Bill of Materials
+
+### What It Is
+
+A formal, machine-readable inventory of every software component (libraries, dependencies, versions) in an application. The analogy: just as physical products have ingredient lists, software should have component lists.
+
+### Standard Formats
+
+| Format | Owner | Best For |
+|--------|-------|---------|
+| **SPDX** | Linux Foundation | Broad ecosystem, NTIA-compliant |
+| **CycloneDX** | OWASP | Security-focused, vulnerability correlations |
+| **SWID** | ISO/IEC 19770 | Enterprise software asset management |
+
+### Generation Tools
+
+| Tool | Language/Ecosystem | Output |
+|------|-------------------|--------|
+| **Syft** (Anchore) | Multi-language, containers | SPDX, CycloneDX |
+| **CycloneDX CLI** | Multi-language | CycloneDX |
+| **grype** (Anchore) | Multi-language | Vulnerability scanner against SBOM |
+| **cosign** | Containers | Sign and verify SBOM artifacts |
+| **trivy** | Containers, filesystems | SBOM + vulnerability scanning |
+| **jake** | Python | pip/conda SBOMs |
+
+### SBOM Workflow in CI/CD
+
+```yaml
+# GitHub Actions — generate SBOM on every release
+- name: Generate SBOM
+  uses: anchore/sbom-action@v0
+  with:
+    format: 'spdx-json'
+    output-file: 'sbom.spdx.json'
+
+- name: Scan SBOM for vulnerabilities
+  uses: anchore/scan-action@v3
+  with:
+    sbom: 'sbom.spdx.json'
+    fail-build: 'true'
+    severity-cutoff: 'high'
+```
+
+### When a CVE Drops: SBOM Value
+
+Without SBOM — manual audit of hundreds of repos, hours or days to determine exposure.
+With SBOM — query: `grep "log4j" */sbom.spdx.json` — instantly know every affected app.
+
+---
+
+## SLSA: Supply-chain Levels for Software Artifacts
+
+### What It Is
+
+Framework created by Google's security team, now under OpenSSF (Open Source Security Foundation). Defines incremental levels of guarantee about how a software artifact was built.
+
+SLSA 1.0 finalized in 2023. Considered baseline for serious supply chain security as of 2025.
+
+### The Four Levels
+
+| Level | Requirements | Guarantees | Achieved By |
+|-------|-------------|-----------|-------------|
+| **SLSA 1** | Build process documented | Minimal — easy starting point | Documentation + any CI |
+| **SLSA 2** | Build by hosted CI service, provenance generated | Build provenance available | GitHub Actions, Google Cloud Build |
+| **SLSA 3** | Isolated build environment, unforgeable provenance, traceable deps | Hard to tamper with build | GitHub Actions with SLSA generator |
+| **SLSA 4** | Hermetic, reproducible build, two-person review | Highest assurance | Advanced build systems |
+
+### SLSA in GitHub Actions
+
+```yaml
+# Generate SLSA provenance automatically with GitHub Actions
+- name: Generate SLSA Provenance
+  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1
+  with:
+    base64-subjects: "${{ needs.build.outputs.hashes }}"
+```
+
+### Verification
+
+```bash
+# Verify artifact provenance
+slsa-verifier verify-artifact my-binary \
+  --provenance-path provenance.intoto.jsonl \
+  --source-uri github.com/my-org/my-repo \
+  --source-tag v1.0.0
+```
+
+---
+
+## Sigstore: Keyless Code Signing
+
+### What It Is
+
+An OpenSSF project that simplifies digital signing of software using OIDC identity instead of long-lived private keys. Components:
+
+| Component | Function |
+|-----------|----------|
+| **Cosign** | CLI to sign/verify containers and other artifacts |
+| **Fulcio** | Certificate Authority — issues short-lived certificates for signatures |
+| **Rekor** | Immutable transparency log — records all signatures |
+
+### Why Keyless Signing Matters
+
+Traditional signing problems:
+- Private keys can leak, be stolen, or get lost
+- Key management is operationally complex
+- Revoking a compromised key is difficult
+
+Sigstore solution:
+1. Developer authenticates via OIDC (GitHub, Google, Microsoft identity)
+2. Fulcio issues a certificate valid for 10 minutes
+3. Cosign uses the certificate to sign the artifact
+4. Signature is recorded in Rekor (immutable, public transparency log)
+5. Certificate expires — no long-lived key to steal
+
+### Signing Containers
+
+```bash
+# Sign a container image
+cosign sign --key cosign.key gcr.io/my-project/my-image:v1.0.0
+
+# Keyless signing (uses OIDC identity from CI environment)
+cosign sign gcr.io/my-project/my-image:v1.0.0
+
+# Verify a signature
+cosign verify \
+  --certificate-identity user@example.com \
+  --certificate-oidc-issuer https://accounts.google.com \
+  gcr.io/my-project/my-image:v1.0.0
+```
+
+### Adoption Status (2025)
+
+- Standard in Kubernetes release builds
+- Standard in many CNCF projects
+- GitHub Container Registry supports automatic Sigstore signing
+- npm and PyPI adding signing support
+
+---
+
+## Dependency Scanning Tools
+
+### SAST (Static Analysis Security Testing)
+
+| Tool | Strengths | Free Tier |
+|------|-----------|-----------|
+| **Snyk Code** | 19+ languages, AI fix suggestions, IDE integration | Yes |
+| **Semgrep** | Custom rule writing, pattern matching, fast | Yes |
+| **SonarQube** | Comprehensive, CI/CD integration | Community edition |
+| **GitHub Advanced Security (GHAS)** | Integrated with GitHub workflow (CodeQL) | For public repos |
+
+### SCA (Software Composition Analysis)
+
+| Tool | Strengths | Free Tier |
+|------|-----------|-----------|
+| **Snyk Open Source** | Largest vulnerability database | Yes |
+| **GitHub Dependabot** | Native GitHub integration, auto-PRs | Yes |
+| **Grype** (Anchore) | Fast, integrates with Syft/SBOM | Yes |
+| **Trivy** | All-in-one: containers + filesystem + SBOM | Yes |
+| **OWASP Dependency-Check** | Widely used, good for enterprise | Yes |
+
+### Secret Scanning
+
+```bash
+# Detect secrets in code before commit
+npx gitleaks detect
+
+# GitHub native — enable in repository settings
+# Settings > Code security > Secret scanning > Enable
+
+# Pre-commit hook with git-secrets
+git secrets --install
+git secrets --register-aws
+```
+
+---
+
+## Dependency Management Best Practices
+
+### Lockfile Discipline
+
+```bash
+# In CI, always use lockfile-enforcing commands
+npm ci          # NOT npm install
+pip install --require-hashes -r requirements.txt
+poetry install --no-root
+
+# Commit lockfiles to version control
+# package-lock.json, yarn.lock, Pipfile.lock — always commit
+```
+
+### Version Pinning Strategy
+
+```json
+// package.json — exact versions, no caret or tilde
+{
+  "dependencies": {
+    "axios": "1.7.2",       // exact — NOT "^1.7.2"
+    "express": "4.18.2"     // exact — NOT "~4.18.2"
+  }
+}
+```
+
+**7-Day Cooldown Rule:** Do not immediately adopt newly published package versions. Malicious packages are often detected within 48-72 hours. Waiting 7 days before updating significantly reduces supply chain risk.
+
+### Automated Updates with Review
+
+```yaml
+# .github/dependabot.yml — automated dependency updates with human review
+version: 2
+updates:
+  - package-ecosystem: "npm"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    groups:
+      production-dependencies:
+        dependency-type: "production"
+      development-dependencies:
+        dependency-type: "development"
+```
+
+### Private Registry Mirror
+
+For high-security environments, mirror public packages through a private registry:
+- **Artifactory** — enterprise-grade with vulnerability scanning
+- **Verdaccio** — open source npm proxy/registry
+- **AWS CodeArtifact** — managed, integrates with IAM
+- This approach allows inspection/approval before packages reach developers
+
+---
+
+## Secure CI/CD Pipeline
+
+### Hardening Checklist
+
+```
+[ ] Secrets stored in vault or CI secrets manager — never in code
+[ ] Branch protection on main — no direct pushes
+[ ] Required code reviews before merge
+[ ] Signed commits (git commit -S)
+[ ] Signed container images (Cosign)
+[ ] SBOM generated and stored with every release
+[ ] Dependency scanning (SCA) in every PR
+[ ] SAST scanning in every PR
+[ ] Secret scanning enabled (GitHub, GitLab)
+[ ] Audit logs for all pipeline runs
+[ ] Least privilege for CI service accounts
+[ ] SLSA Level 2+ provenance for releases
+```
+
+### GitHub Actions Security
+
+```yaml
+# Minimal permissions for workflow
+permissions:
+  contents: read      # Only what's needed
+  security-events: write  # For uploading security results
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      # Pin actions to specific commit SHA, not tag
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
+      
+      # Never: actions/checkout@v4 (tag can be moved)
+```
+
+---
+
+## Sources
+
+- NIST SP 800-218 (SSDF): https://csrc.nist.gov/publications/detail/sp/800-218/final
+- OpenSSF SLSA: https://slsa.dev/
+- Sigstore: https://sigstore.dev/
+- CISA Software Supply Chain Security: https://www.cisa.gov/software-supply-chain-security
+- Anchore SBOMs 2025: https://anchore.com/blog/software-supply-chain-security-in-2025-sboms-take-center-stage/
+- OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/