sinapse-ai 9.2.0 → 9.3.0

package/squads/squad-cybersecurity/knowledge-base/owasp-top-10-reference.md

@@ -0,0 +1,362 @@
+# OWASP Top 10 Reference — 2025 Edition
+
+## Purpose
+
+Complete OWASP Top 10 2025 reference with mitigations, code examples, and detection tools. Used by Breach (penetration-tester), Govern (compliance-officer), and any agent performing security review.
+
+**Source authority:** OWASP Foundation — owasp.org/Top10/2025/
+**Last updated in KB:** April 2026
+
+---
+
+## What Changed from 2021 to 2025
+
+| # | 2025 | Change from 2021 |
+|---|------|-----------------|
+| A01 | Broken Access Control | Maintained — still #1 (94% of apps tested) |
+| A02 | Security Misconfiguration | Rose from #5 to #2 |
+| A03 | Software Supply Chain Failures | EXPANDED from "Vulnerable and Outdated Components" — npm attacks of 2025 drove this |
+| A04 | Cryptographic Failures | Maintained |
+| A05 | Injection | Maintained — SQL, NoSQL, OS Command, LDAP |
+| A06 | Insecure Design | Maintained |
+| A07 | Authentication Failures | Maintained |
+| A08 | Software or Data Integrity Failures | Maintained — CI/CD pipelines, unsigned updates |
+| A09 | Security Logging and Alerting Failures | Renamed (was "Insufficient Logging & Monitoring") |
+| A10 | Mishandling of Exceptional Conditions | NEW — fail-open behaviors, stack traces exposed |
+
+---
+
+## A01 — Broken Access Control
+
+**Prevalence:** 94% of applications tested had some form of broken access control.
+
+**What it is:** A user can access resources, data, or functions they should not have permission to. Includes IDOR (Insecure Direct Object Reference), privilege escalation, forced browsing, JWT manipulation.
+
+**Attack examples:**
+- Changing `?user_id=123` to `?user_id=456` to access another user's data
+- Accessing admin endpoints without admin role
+- Manipulating JWT claims to elevate privileges
+
+**Code — Wrong vs Right:**
+```typescript
+// WRONG: trusts parameter without authorization check
+app.get('/api/users/:id', async (req, res) => {
+  const user = await db.getUser(req.params.id)
+  res.json(user) // Anyone can access any user
+})
+
+// RIGHT: verify caller owns the resource
+app.get('/api/users/:id', async (req, res) => {
+  if (req.params.id !== req.user.id && !req.user.isAdmin) {
+    return res.status(403).json({ error: 'Forbidden' })
+  }
+  const user = await db.getUser(req.params.id)
+  res.json(user)
+})
+```
+
+**Mitigations:**
+- Deny access by default — allowlist, not denylist
+- Implement access control at the server, not client
+- Use Row Level Security (RLS) in databases (Supabase pattern)
+- Log access control failures and alert on suspicious patterns
+- Rate limit API endpoints to prevent automated enumeration
+
+---
+
+## A02 — Security Misconfiguration
+
+**Prevalence:** Rose significantly in 2025. Encompasses cloud misconfigurations, default credentials, verbose error messages, unnecessary features enabled.
+
+**Attack examples:**
+- Default admin credentials unchanged (admin/admin)
+- S3 bucket / Azure Blob with public access enabled
+- Verbose stack traces returned in API responses
+- Development debug endpoints left enabled in production
+- CORS set to `*` (wildcard)
+
+**Mitigations:**
+- Implement a repeatable hardening process — infrastructure as code (IaC) enforces baseline
+- Remove unused features, frameworks, components
+- Review and update security configurations as part of patch management
+- Use automated scanning (Scout Suite for AWS, Prowler for multi-cloud)
+- Never expose stack traces to end users
+
+**Security Headers (mandatory in production):**
+```
+Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: geolocation=(), camera=(), microphone=()
+Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; frame-ancestors 'none';
+```
+
+---
+
+## A03 — Software Supply Chain Failures
+
+**CRITICAL 2025 CONTEXT:** Real-world attacks that drove this category's expansion:
+
+| Date | Package | Weekly Downloads | Attack Vector |
+|------|---------|-----------------|---------------|
+| Sep 2025 | debug, chalk + 16 others | 2.6 billion total | Maintainer phishing |
+| Mar 2026 | Axios | 100M+ | Credential theft (North Korean APT) |
+
+**What it is:** Compromised dependencies, typosquatting packages, malicious maintainer takeovers, unsigned artifacts.
+
+**Mandatory defenses:**
+```bash
+# Always use lockfile in CI — npm ci respects lockfile exactly
+npm ci  # NOT npm install
+
+# Audit regularly
+npm audit --audit-level=high
+
+# Pin exact versions in package.json — no caret operators
+"dependencies": {
+  "axios": "1.7.2"  # exact, not "^1.7.2"
+}
+
+# Configure Dependabot for weekly automated updates
+# .github/dependabot.yml
+version: 2
+updates:
+  - package-ecosystem: "npm"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+
+# Detect secrets in code
+npx gitleaks detect
+
+# 7-day cooldown: do not immediately adopt newly published versions
+```
+
+**SBOM (Software Bill of Materials):** Generate and maintain an SBOM so you can instantly answer "does our app use vulnerable-library-X?" when a CVE drops. Tools: Syft (Anchore), CycloneDX CLI, grype for scanning.
+
+---
+
+## A04 — Cryptographic Failures
+
+**What it is:** Data transmitted or stored without encryption, weak algorithms, poor key management.
+
+**Attack examples:**
+- Passwords stored as plain text or MD5
+- Sensitive data transmitted over HTTP
+- Private keys committed to repositories
+- Use of deprecated algorithms (DES, RC4, MD5 for integrity)
+
+**Algorithm guidance:**
+
+| Use Case | Recommended | Deprecated (Do Not Use) |
+|----------|-------------|------------------------|
+| Password hashing | Argon2id, bcrypt, PBKDF2 | MD5, SHA1, unsalted SHA2 |
+| Symmetric encryption | AES-256-GCM, ChaCha20-Poly1305 | DES, 3DES, RC4 |
+| Asymmetric | RSA-4096, ECDSA-P256, Ed25519 | RSA-1024, DSA |
+| TLS | 1.2 (minimum), 1.3 (recommended) | SSLv3, TLS 1.0, TLS 1.1 |
+| Hashing (non-password) | SHA-256, SHA-3 | MD5, SHA1 |
+| Key exchange | ECDH, X25519 | DH < 2048-bit |
+
+**Mitigations:**
+- Classify data and apply protection levels (TLS in transit, AES at rest)
+- Do not cache sensitive data unnecessarily
+- Store passwords using a modern hashing algorithm with salting
+- Disable deprecated TLS protocol versions at the load balancer/reverse proxy
+
+---
+
+## A05 — Injection
+
+**What it is:** Untrusted data sent to an interpreter as part of a command or query. SQL, NoSQL, OS command, LDAP, XPath, XML injection.
+
+**Code — SQL Injection:**
+```javascript
+// FORBIDDEN: string interpolation creates SQL injection vector
+const query = `SELECT * FROM users WHERE name = '${userInput}'`
+
+// REQUIRED: parameterized queries
+const query = 'SELECT * FROM users WHERE name = $1'
+const result = await db.query(query, [userInput])
+
+// Supabase: already parameterized — safe
+const { data } = await supabase.from('users').select('*').eq('name', userInput)
+```
+
+**Mitigations:**
+- Use parameterized queries or ORMs — never string concatenation
+- Validate and sanitize all user input with a schema (Zod, Joi)
+- Apply least privilege on database accounts — app user should not have DROP or DDL rights
+- Use WAF rules for SQL injection patterns as defense-in-depth
+
+---
+
+## A06 — Insecure Design
+
+**What it is:** Design flaws, not implementation bugs. Missing threat modeling, no rate limits on sensitive flows, missing security requirements from the start.
+
+**Examples:**
+- A password reset flow that lacks rate limiting or account enumeration protection
+- A multi-tenant application where tenant isolation is not a design requirement
+- An API that leaks internal IDs enabling enumeration attacks
+
+**Mitigations:**
+- Threat model before coding — use STRIDE framework
+- Define security requirements alongside functional requirements
+- Implement rate limiting on all sensitive endpoints (auth, password reset, payment)
+- Adopt secure design patterns: defense in depth, fail securely, least privilege
+
+---
+
+## A07 — Authentication Failures
+
+**What it is:** Weaknesses in authentication and session management. Brute force, session hijacking, credential stuffing, weak tokens.
+
+**JWT Security Best Practices:**
+
+| Practice | Detail |
+|---------|--------|
+| Storage | httpOnly cookies — NEVER localStorage (XSS vulnerable) |
+| Expiration | Access token: 5-15 min. Refresh token: 7-30 days |
+| Algorithm | EdDSA (preferred) or ES256. Avoid RS256 for new projects |
+| Secret | Minimum 64 characters, cryptographically generated |
+| Transport | HTTPS only — never send tokens over HTTP |
+| Validation | Always verify signature, exp, iss, aud server-side |
+
+**Password hashing:**
+
+| Algorithm | Recommendation | Notes |
+|-----------|---------------|-------|
+| Argon2id | Ideal | Most modern, GPU-resistant |
+| bcrypt | Recommended | Most common in Node.js |
+| PBKDF2 | Acceptable | When bcrypt/Argon2 unavailable |
+| MD5/SHA1 | PROHIBITED | Never use for passwords |
+
+**Session management requirements:**
+- Generate session IDs with at least 64 bits of entropy
+- Regenerate session ID after successful authentication (prevents session fixation)
+- Invalidate sessions both client-side and server-side on logout
+- Implement inactivity timeout
+
+---
+
+## A08 — Software and Data Integrity Failures
+
+**What it is:** Assumptions about software updates, critical data, and CI/CD pipelines without integrity verification. Includes insecure deserialization.
+
+**Examples:**
+- CI/CD pipeline that can be poisoned via unprotected secrets
+- Application downloading unsigned/unverified plugins or updates
+- Deserializing objects from untrusted sources (Java serialization, pickle)
+
+**Mitigations:**
+- Use digital signatures for code releases (Sigstore, GPG)
+- Ensure packages come from trusted registries with integrity checking
+- Protect CI/CD pipeline — secrets stored in vault, branch protections on main
+- Do not deserialize objects from untrusted sources without validation
+
+---
+
+## A09 — Security Logging and Alerting Failures
+
+**What it is:** Insufficient logging means breaches go undetected. Average breach dwell time without good logging: 287 days (IBM Cost of Data Breach 2025).
+
+**What you must log:**
+- Authentication events (login, logout, failures)
+- Access control failures
+- Input validation failures
+- High-value transactions
+- Admin operations
+
+**What you must NOT log:**
+- Passwords or password hashes
+- Session tokens or API keys
+- Credit card numbers or PII (mask if needed)
+- Full request bodies containing sensitive data
+
+**Alerting requirements:**
+- Alert on brute force patterns (5+ failed logins from same IP in 10 minutes)
+- Alert on access control failures from authenticated users
+- Alert on spikes in 4xx/5xx error rates
+- Alert on mass data exports or downloads
+
+---
+
+## A10 — Mishandling of Exceptional Conditions (NEW in 2025)
+
+**What it is:** Applications that fail-open (grant access when error occurs) or expose internal details in error messages. Stack traces reveal file paths, database schema, framework versions.
+
+**Code — Wrong vs Right:**
+```typescript
+// WRONG: exposes internal stack trace
+app.get('/api/data', async (req, res) => {
+  try {
+    const data = await fetchData()
+    res.json(data)
+  } catch (error) {
+    res.status(500).json({ error: error.stack }) // NEVER do this
+  }
+})
+
+// RIGHT: fail-closed, detailed internal log, generic external message
+app.get('/api/data', async (req, res) => {
+  try {
+    const data = await fetchData()
+    res.json(data)
+  } catch (error) {
+    console.error('Internal error:', error) // detailed internal log
+    res.status(500).json({ error: 'Internal server error' }) // generic external
+  }
+})
+```
+
+**Mitigations:**
+- Implement global error handler that never leaks internal details
+- Use structured logging for internal details, generic messages for clients
+- Test error paths explicitly — ensure they fail-closed (deny access on error)
+- Remove default error pages that expose framework/server versions
+
+---
+
+## Detection Tools Mapping
+
+| OWASP Category | SAST | DAST | SCA |
+|---------------|------|------|-----|
+| A01 Broken Access Control | Semgrep, CodeQL | Burp Suite, ZAP | — |
+| A02 Misconfiguration | Checkov, Prowler | Scout Suite, ZAP | — |
+| A03 Supply Chain | — | — | Snyk, Dependabot, Grype |
+| A04 Crypto Failures | Semgrep, SonarQube | SSLyze | — |
+| A05 Injection | Semgrep, CodeQL | Burp Suite, SQLmap | — |
+| A06 Insecure Design | Manual review | Threat modeling | — |
+| A07 Auth Failures | Semgrep | Burp Suite, Hydra | — |
+| A08 Integrity Failures | — | — | Cosign, Syft |
+| A09 Logging Failures | Manual review | Log analysis | — |
+| A10 Exception Handling | Semgrep | Manual testing | — |
+
+---
+
+## OWASP API Security Top 10 (2023 — still current)
+
+For API-specific security testing, use the parallel API Security Top 10:
+
+| # | Category | Key Risk |
+|---|----------|---------|
+| API1 | Broken Object Level Authorization (BOLA) | Accessing other users' objects by ID |
+| API2 | Broken Authentication | Weak/missing auth on API endpoints |
+| API3 | Broken Object Property Level Authorization | Over-exposure of object properties |
+| API4 | Unrestricted Resource Consumption | No rate limiting on resource-intensive endpoints |
+| API5 | Broken Function Level Authorization | Users accessing admin functions |
+| API6 | Unrestricted Access to Sensitive Business Flows | Automated abuse of business logic |
+| API7 | Server-Side Request Forgery | API calls forged to internal resources |
+| API8 | Security Misconfiguration | Default configs, verbose errors |
+| API9 | Improper Inventory Management | Shadow APIs, undocumented endpoints |
+| API10 | Unsafe Consumption of APIs | Trusting third-party APIs without validation |
+
+---
+
+## Sources
+
+- OWASP Top 10 2025: https://owasp.org/Top10/2025/
+- OWASP API Security Top 10 2023: https://owasp.org/API-Security/
+- OWASP Testing Guide v4.2: https://owasp.org/www-project-web-security-testing-guide/
+- OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/

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/