Imported from Hack23/cia (.github/skills/hack23-information-security-policy/SKILL.md). Install upstream with npx skills add Hack23/cia --skill hack23-information-security-policy. Copyright stays with the author (Apache-2.0).

Hack23 Information Security Policy Integration Skill

Purpose

Translate the Hack23 Information Security Policy — the apex document of the Hack23 ISMS — into concrete, enforceable engineering behaviour for the CIA platform. This skill connects the high-level policy (CIA triad objectives, risk appetite, roles, legal duties) to the code, workflows, reviews, and evidence that actually implement it.

Where hack23-isms-compliance describes the framework and information-security-strategy describes the strategy, this skill tells an engineer or AI agent "given the ISP and its supporting policies, what must I do in this commit, PR, or design?"

When to Use

Apply this skill when:

• ✅ Starting or reviewing any code / infrastructure / documentation change that touches data, authentication, authorization, crypto, logging, or third-party integrations
• ✅ Creating or updating a GitHub issue or PR that is security-relevant
• ✅ Onboarding a new contributor, AI agent, or repository to Hack23 standards
• ✅ Responding to a CodeQL / SonarCloud / OWASP / Dependabot finding
• ✅ Classifying data, designing an API, or integrating an external source
• ✅ Preparing release notes, SBOM, SECURITY.md, or audit evidence
• ✅ Assessing whether an AI coding agent action is policy-compliant

Do NOT use for:

• ❌ Tactical incident response (use incident-response skill)
• ❌ Deep cryptographic implementation (use crypto-best-practices / cryptography-policy)
• ❌ Framework-level compliance mapping only (use hack23-isms-compliance)

Information Security Policy — Core Tenets (Engineering View)

The ISP is binding on all contributors, including AI agents. Its five engineering-relevant tenets are:

Supporting Policies and When Each Applies

The ISP is implemented through these supporting policies. An AI agent or developer MUST consult the ones that apply to the task at hand.

SDLC × ISP Responsibility Matrix

Each phase has mandatory ISP-derived checks. AI agents must confirm all items for their phase before proceeding.

┌────────────────┬──────────────────────────────────────────────────────────┐
│ SDLC Phase     │ ISP-Derived Gate                                         │
├────────────────┼──────────────────────────────────────────────────────────┤
│ Plan           │ Classification set; threat model updated; DPIA if needed │
│ Design         │ Least privilege; trust boundaries; crypto choices per    │
│                │ Cryptography Policy; third-party review                  │
│ Implement      │ Banned patterns avoided; input validation; output        │
│                │ encoding; parameterized queries; no secrets              │
│ Review         │ CODEOWNERS; SoD (author ≠ approver); PR template met    │
│ Build          │ Pinned actions; reproducible; signed; SBOM generated     │
│ Test           │ ≥80% line / ≥70% branch; CodeQL + SCA pass; DAST         │
│                │ baseline; negative test cases                            │
│ Release        │ Signed artifacts; SLSA provenance; release notes;        │
│                │ security advisories closed                               │
│ Operate        │ Logging (no PII); alerting; rotation; DR test            │
│ Respond        │ Incident plan triggers; 72h GDPR notification path       │
│ Retire         │ Secure data deletion; key destruction; dep removal       │
└────────────────┴──────────────────────────────────────────────────────────┘

Non-Negotiable Rules (from ISP §Acceptable Use / §Secure Engineering)

🔴 Never:

• Commit secrets, tokens, keys, or personal data — use GitHub Secrets / AWS SSM
• Disable a security control (CSRF, CSP, TLS, CodeQL) without a risk-accepted PR + CEO sign-off
• Introduce a dependency without vulnerability + license check
• Bypass CODEOWNERS, branch protection, or the signed-commit requirement
• Log request bodies, tokens, passwords, or classified data
• Ship a release with open Critical or High CVEs
• Use an unpinned GitHub Action in a workflow that has write permissions
• Process personal data without a lawful basis documented in the DPIA

🟢 Always:

• Classify new data (Public / Internal / Confidential / Restricted)
• Default to deny in authorization checks
• Parameterize all database queries
• Encode output at the rendering boundary (Vaadin ContentMode.TEXT)
• Use @Transactional with explicit boundaries; readOnly = true where applicable
• Add unit tests for the negative / unauthorized path
• Sign commits (GPG or SSH) and releases (Sigstore/cosign)
• Record security-relevant decisions in SECURITY_ARCHITECTURE.md / THREAT_MODEL.md

AI Agent & Copilot Guardrails (ISP + AI Policy)

These rules bind every AI agent (task-agent, stack-specialist, etc.) operating in this repo:

1. Read before act — load README, copilot-instructions, and the ISP before making changes
2. Classification awareness — never escalate Public → Confidential exposure inadvertently
3. Minimal diff — surgical, auditable changes; no unrelated refactors
4. Evidence first — every security claim cites scanner output, ISMS control, or test
5. Human-in-the-loop — Critical/High security changes require human approval before merge
6. Transparent reasoning — PR descriptions link to ISP / supporting policy when relevant
7. No secret handling — agents never print, commit, or send secrets; only reference names

PR Policy Compliance Checklist

Paste into PR description for any security-relevant change:

### ISP & Supporting Policy Compliance
- [ ] Change scope and classification documented
- [ ] Threat model impact assessed (STRIDE) or confirmed N/A
- [ ] Secure Development Policy checks pass (CodeQL, SonarCloud, OWASP, SpotBugs)
- [ ] Secrets Management Policy respected (no secrets, rotation considered)
- [ ] Cryptography Policy respected (approved algorithms, key storage)
- [ ] Access Control Policy respected (least privilege, deny-by-default)
- [ ] Data Protection / Privacy Policy respected (GDPR basis, retention)
- [ ] Third Party Management respected (license, CVE, attribution)
- [ ] Open Source Policy respected (SBOM, signed release, badges)
- [ ] Logging reviewed (no PII, no secrets, useful for IR)
- [ ] Negative-path tests added
- [ ] SECURITY_ARCHITECTURE.md / THREAT_MODEL.md updated if needed

Evidence & Audit Trail

Every security claim is backed by machine-verifiable evidence:

ISMS Framework Mapping

References

• Information Security Policy — apex policy
• All Hack23 ISMS Policies
• Secure Development Policy
• Open Source Policy
• Information Security Strategy
• AI Policy
• Related skills: hack23-isms-compliance, information-security-strategy, secure-development-policy, open-source-policy, compliance-frameworks