🛡️ Secure Development Policy Skill

🎯 Purpose Statement

Apply Hack23 AB's Secure Development Policy to demonstrate how security-by-design creates competitive advantages through systematic DevSecOps implementation.

Reference: Hack23 Secure Development Policy

This skill provides comprehensive guidance for implementing all phases of the secure development lifecycle with clear, actionable requirements following STYLE_GUIDE.md icon standards.

🔄 Secure Development Lifecycle (SDLC) - All Phases

📋 Phase 1: Planning & Design

Clear Requirements:

✅ Complete project classification per Classification Framework
✅ Document CIA triad levels (Confidentiality, Integrity, Availability)
✅ Define RTO/RPO aligned with business impact
✅ Create SECURITY_ARCHITECTURE.md with Mermaid C4 diagrams
✅ Perform STRIDE threat modeling documented in THREAT_MODEL.md
✅ Complete risk assessment integrated with Risk Register
✅ Calculate security investment ROI based on classification

Deliverables Checklist:

README.md includes "Project Classification" section
SECURITY_ARCHITECTURE.md created with current state
FUTURE_SECURITY_ARCHITECTURE.md created with roadmap
THREAT_MODEL.md includes STRIDE analysis
Risk assessment documented and registered
Cost-benefit analysis approved by CEO

💻 Phase 2: Development

Clear Requirements:

✅ Follow OWASP Top 10 secure coding standards
✅ Implement language-specific security best practices
✅ Require security-focused code review for all changes
✅ Apply data classification to all code assets
✅ Use GitHub secrets, never hardcode credentials
✅ Implement secret rotation procedures
✅ Use parameterized queries (no SQL injection)
✅ Validate and sanitize all inputs
✅ Encode outputs appropriately for context
✅ Implement proper error handling (no information disclosure)

Code Review Security Checklist:

🧪 Phase 3: Security Testing

Clear Requirements:

🔬 SAST (Static Application Security Testing)

✅ SonarCloud integration on every commit
✅ Quality gate must pass (no Critical/High vulnerabilities)
✅ Security hotspots reviewed and resolved
✅ Code coverage ≥80% lines, ≥70% branches

📦 SCA (Software Composition Analysis)

✅ Automated dependency scanning (Dependabot/Renovate)
✅ SBOM generation (CycloneDX or SPDX format)
✅ License compliance via FOSSA scanning
✅ Vulnerability remediation per classification SLAs:
- Critical: 24 hours
- High: 7 days
- Medium: 30 days
- Low: 90 days

⚡ DAST (Dynamic Application Security Testing)

✅ OWASP ZAP scanning in staging environment
✅ API security testing (authentication, authorization, input validation)
✅ Annual penetration testing for High/Critical projects

🔍 Secret Scanning

✅ GitHub secret scanning enabled
✅ Pre-commit hooks prevent secret commits
✅ Immediate rotation for any exposed secrets

🔒 Test Data Protection

✅ NEVER use production data in test environments
✅ Anonymize/pseudonymize/mask all test data
✅ Securely delete test data after use
✅ Restrict test environment access (least privilege)

🚀 Phase 4: Deployment

Clear Requirements:

✅ Automated CI/CD with security gates
✅ All GitHub Actions pinned to SHA commits
✅ Harden-runner enabled with egress auditing
✅ Least privilege permissions in workflows
✅ Manual approval required for production
✅ Deployment checklist completed
✅ Security metrics and monitoring configured
✅ Rollback plan documented and tested

GitHub Actions Security Pattern:

permissions:
  contents: read  # Least privilege default

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: step-security/harden-runner@<SHA>
        with:
          egress-policy: audit
      
      - uses: actions/checkout@<SHA>
      
      # Pin ALL actions to SHA, not tags

🔧 Phase 5: Maintenance & Operations

Clear Requirements:

✅ Active vulnerability management per Vulnerability Management
✅ Security metrics tracked per Security Metrics
✅ Regular dependency updates (automated via Dependabot)
✅ Security patches applied per classification SLAs
✅ Incident response integration per Incident Response Plan
✅ Annual security review and threat model update
✅ Quarterly dependency and license audits
✅ Continuous monitoring and alerting

Monitoring Requirements:

Security event logging enabled
SIEM integration configured
Vulnerability alerts routed to security team
Performance metrics track security impact
Compliance dashboards updated real-time

🤖 AI-Augmented Development Controls

Clear Requirements for ALL AI-assisted development:

🔐 AI as Proposal Generator Only

✅ All AI outputs require human review and approval
✅ AI cannot bypass CI/CD, security gates, or approvals
✅ Human developer retains accountability for all changes
✅ AI cannot weaken security controls
✅ AI cannot autonomously deploy to production

📋 Mandatory PR Review Process

✅ All AI-assisted code goes through standard PR workflow
✅ PR description documents AI assistance used
✅ Security gates enforced (no exceptions for AI)
✅ Human reviewer verifies security controls intact
✅ Testing requirements unchanged (80%+ coverage)

🔧 Curator-Agent Governance

✅ Changes to .github/agents/*.md require CEO approval
✅ Changes to .github/copilot-mcp*.json require CEO approval
✅ Changes to .github/workflows/copilot-setup-steps.yml require CEO approval
✅ Treat as Normal Changes per Change Management
✅ Document risk assessment for capability expansion
✅ All new integrations require security review

🛡️ Security & Audit Requirements

✅ Agents operate with least-privilege tool access
✅ MCP configurations under change control
✅ All agent activities logged and auditable
✅ Capability expansion requires security review
✅ Quarterly agent ecosystem security audit

🎯 Unit Test Coverage Requirements

Clear Requirements:

✅ Minimum 80% line coverage
✅ Minimum 70% branch coverage
✅ Tests run on every commit and PR
✅ UnitTestPlan.md documented in repository
✅ Public coverage reports via badges
✅ Historical coverage tracking (no regression)
✅ Coverage reports published to public URL

Reference Implementations:

🏛️ CIA: Unit Tests • Coverage • Plan
🎮 Black Trigram: Tests • Coverage • Plan
📊 CIA Compliance Manager: Tests • Coverage • Plan

🌐 End-to-End Testing Requirements

Clear Requirements:

✅ All critical user journeys covered
✅ E2ETestPlan.md documented in repository
✅ Public Mochawesome/Cypress reports
✅ Cross-browser testing (Chrome, Firefox, Safari)
✅ Performance assertions within tests
✅ Authentication/authorization flows tested
✅ Error handling and edge cases covered

Reference Implementations:

🏛️ CIA: E2E Plan
🎮 Black Trigram: E2E Tests • Plan
📊 CIA Compliance Manager: E2E Tests • Plan

🕷️ Threat Modeling Requirements

Clear Requirements per Threat Modeling Policy:

📋 Required Documentation

✅ THREAT_MODEL.md in repository root
✅ STRIDE framework application (all 6 categories)
✅ MITRE ATT&CK technique mapping
✅ Attack tree analysis with probability/impact
✅ Threat agent classification (external/internal/supply chain)
✅ Quantitative risk assessment with business impact
✅ Security control mapping with effectiveness validation

🔄 Maintenance Requirements

✅ Threat model created during design phase
✅ Updated for all architectural changes
✅ Annual comprehensive review
✅ Quarterly update cycle
✅ Incident-driven updates after security events

Reference Implementations:

🏛️ CIA: Threat Model • STRIDE • Attack Trees
🎮 Black Trigram: Threat Model • Gaming Security
📊 CIA Compliance Manager: Threat Model • Risk Assessment

🎖️ Public Evidence Requirements

Clear Requirements per STYLE_GUIDE.md:

Required Badges in README.md

✅ OpenSSF Scorecard (target: ≥7.0)
✅ CII Best Practices (minimum: Passing)
✅ SLSA Level 3 attestation
✅ SonarCloud Quality Gate (must be "Passed")
✅ Code Coverage badge (≥80%)
✅ License badge (OSI-approved)
✅ Threat Model link badge

Example Badge Configuration:

[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/ORG/REPO/badge)](https://scorecard.dev/viewer/?uri=github.com/ORG/REPO)
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/ID/badge)](https://bestpractices.coreinfrastructure.org/projects/ID)
[![Quality Gate](https://sonarcloud.io/api/project_badges/measure?project=ORG_REPO&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=ORG_REPO)
[![Coverage](https://sonarcloud.io/api/project_badges/measure?project=ORG_REPO&metric=coverage)](https://sonarcloud.io/summary/new_code?id=ORG_REPO)
[![Threat Model](https://img.shields.io/badge/Threat_Model-Documentation-blue)](https://github.com/ORG/REPO/blob/main/THREAT_MODEL.md)

📋 Master Verification Checklist

Use this comprehensive checklist before ANY deployment:

Phase 1: Planning & Design ✅

Project classification complete (CIA + RTO/RPO + Business Impact)
SECURITY_ARCHITECTURE.md created with C4 diagrams
FUTURE_SECURITY_ARCHITECTURE.md created with roadmap
THREAT_MODEL.md includes STRIDE + MITRE ATT&CK
Attack trees documented with probability/impact
Risk assessment registered
Cost-benefit analysis approved

Phase 2: Development ✅

OWASP Top 10 mitigations implemented
Language-specific security standards followed
Code review completed with security focus
Asset classification applied
No hardcoded secrets (verified with secret scanning)
Input validation implemented
Output encoding implemented
Error handling doesn't leak sensitive info
Logging captures security events

Phase 3: Testing ✅

SAST passed (SonarCloud quality gate green)
SCA clean (all vulnerabilities remediated per SLA)
DAST completed (OWASP ZAP scan clean)
Secret scanning clean
Test data properly anonymized
Unit test coverage ≥80% lines, ≥70% branches
E2E tests cover all critical paths
UnitTestPlan.md documented
E2ETestPlan.md documented

Phase 4: Deployment ✅

Phase 5: Operations ✅

AI Controls ✅

Documentation ✅

Public Evidence ✅

📚 Authoritative References

Primary Policy: Secure Development Policy
Related Policies:
Standards: STYLE_GUIDE.md

💡 Key Takeaways

🛡️ Security by Design: Build security in from the start, not bolt on later
🌟 Transparency: Public evidence through badges and documentation
🏷️ Classification-Driven: All decisions aligned with project classification
🔄 Continuous Improvement: Regular reviews, updates, and learning from incidents
🤖 Human Accountability: AI assists, humans decide and approve
📊 Evidence-Based: Every security claim backed by public, verifiable proof
✅ Comprehensive Coverage: ALL 5 SDLC phases with clear, actionable requirements

secure-development-policy

🛡️ Secure Development Policy Skill

🎯 Purpose Statement

🔄 Secure Development Lifecycle (SDLC) - All Phases

📋 Phase 1: Planning & Design

💻 Phase 2: Development

🧪 Phase 3: Security Testing

🔬 SAST (Static Application Security Testing)

📦 SCA (Software Composition Analysis)

⚡ DAST (Dynamic Application Security Testing)

🔍 Secret Scanning

🔒 Test Data Protection

🚀 Phase 4: Deployment

🔧 Phase 5: Maintenance & Operations

🤖 AI-Augmented Development Controls

🔐 AI as Proposal Generator Only

📋 Mandatory PR Review Process

🔧 Curator-Agent Governance

🛡️ Security & Audit Requirements

🎯 Unit Test Coverage Requirements

🌐 End-to-End Testing Requirements

🕷️ Threat Modeling Requirements

📋 Required Documentation

🔄 Maintenance Requirements

🎖️ Public Evidence Requirements

Required Badges in README.md

📋 Master Verification Checklist

Phase 1: Planning & Design ✅

Phase 2: Development ✅

Phase 3: Testing ✅

Phase 4: Deployment ✅

Phase 5: Operations ✅

AI Controls ✅

Documentation ✅

Public Evidence ✅

📚 Authoritative References

💡 Key Takeaways