CRA Conformity Assessment

Home Manifesto ISMS

🛡️ CRA Conformity Assessment: Brussels Demands Documentation (We Already Have It)

Evidence-Driven Conformity: Three Complete CRA Assessments

Nothing is true. Everything is permitted. Except selling products with digital elements in the EU without documentation—that's CRA non-compliance.

Think for yourself. Question authority. But comply with Brussels when you want market access. At Hack23, we don't wait for regulations—we document systematically as operational excellence.

The Cyber Resilience Act (CRA) requires cybersecurity documentation for products with digital elements. Most companies will scramble. We already have it. Three complete CRA assessments: CIA (political transparency) | Black Trigram (educational gaming) | CIA Compliance Manager (security assessment). SLSA 3 attestations, OpenSSF Scorecard 7.2+, complete SBOM, public threat models—all evidence-linked and GitHub-verified.

ILLUMINATION: CRA exists because manufacturers shipped insecure products for decades. Brussels weaponized compliance. Smart organizations already documented security—CRA just standardizes the format.

Our CRA Conformity Assessment Process isn't theoretical—it's operational across all projects. This demonstrates our cybersecurity consulting expertise through public evidence of regulatory compliance excellence.

Three Complete CRA Assessments: Public Evidence Portfolio

Hack23 demonstrates CRA compliance expertise through three fully-documented reference implementations:

ProjectProduct TypeCRA ClassificationEvidence Links
🕵️ CIAPolitical transparency platformStandard (Non-commercial OSS)CRA Assessment | SLSA Attestations
⚫ Black TrigramKorean martial arts gameStandard (Non-commercial OSS)CRA Assessment | SLSA Attestations
🛡️ CIA Compliance ManagerCompliance automation toolStandard (Non-commercial OSS)CRA Assessment | SLSA Attestations

Each assessment includes:

  • Product Identification: CIA classification levels (Confidentiality, Integrity, Availability), RTO/RPO metrics, market category
  • CRA Scope Classification: Non-commercial OSS, community distribution, Standard CRA class (self-assessment)
  • Technical Documentation: Architecture, SBOM, cybersecurity controls, supply chain security, update mechanisms
  • Risk Assessment: Supply chain attacks, unauthorized access, data breaches, component vulnerabilities, service disruption
  • Essential Requirements: Secure by design, secure by default, vulnerability disclosure, security monitoring
  • Conformity Evidence: SLSA 3 attestations, OpenSSF Scorecard 7.2+, SBOM (SPDX + CycloneDX), test coverage reports

EVIDENCE ILLUMINATION: Each assessment links to immutable GitHub attestations. This isn't marketing fluff—it's cryptographically verifiable supply chain security.

The Five Pillars of CRA Conformity Assessment

1. 📋 Product Identification

CRA Annex V § 1 compliance. Each project documented with: product name, version tag, repository URL, security contact (security@hack23.org), purpose statement, market category (non-commercial OSS), CIA classification (Confidentiality, Integrity, Availability levels), RTO/RPO metrics.

Classification drives security investment. CIA framework extends traditional CIA Triad with business continuity metrics.

2. 🏗️ Technical Documentation

CRA Annex V § 2 requirements. Architecture documentation, complete SBOM (SPDX + CycloneDX), cybersecurity controls (Access Control + Cryptography policies), supply chain security (SLSA 3 provenance), secure update mechanisms, security monitoring, data protection (Data Classification Policy), vulnerability disclosure (SECURITY.md).

Documentation linked to ISMS policies. Systematic integration, not ad-hoc paperwork.

3. ⚠️ Risk Assessment

CRA Annex V § 3 documentation. Five risk categories analyzed: supply chain attacks (SBOM + SLSA), unauthorized access (MFA + secret scanning), data breaches (encryption + IAM), component vulnerabilities (SCA scanning + patch management), service disruption (WAF + DDoS protection). Each risk quantified with likelihood, impact (C/I/A), controls, residual risk. Links to Risk Assessment Methodology and Risk Register.

Risk quantification based on measurable business impact, not paranoid guesswork.

4. ✅ Essential Requirements

CRA Annex I self-assessment. Eight essential requirements documented: Secure by Design (minimal attack surface via SECURITY_ARCHITECTURE.md), Secure by Default (hardened configurations), Personal Data Protection (GDPR compliance via Data Classification), Vulnerability Disclosure (public VDP via SECURITY.md), SBOM (automated generation in releases), Secure Updates (signed with attestations), Security Monitoring (comprehensive logging via Incident Response Plan), Security Documentation (USER_SECURITY_GUIDE.md).

Requirements mapped to ISMS policies. Systematic compliance, not checkbox theater.

5. 🎖️ Conformity Evidence

CRA Article 19 documentation. SLSA 3 attestations (supply chain provenance), OpenSSF Scorecard 7.2+ (security best practices), CII Best Practices badges, SonarCloud quality gates (code quality), FOSSA license compliance, test coverage ≥80% line/≥70% branch, zero critical vulnerabilities (SAST + SCA + secret scanning), public GitHub attestations for verification.

Evidence cryptographically verifiable. Trust through transparency, not marketing claims.

Supply Chain Security: SLSA 3 + OpenSSF Scorecard

CRA demands supply chain transparency. We provide cryptographic proof:

ControlRequirementHack23 ImplementationEvidence
SLSA ProvenanceLevel 3 attestationGitHub Actions automated build attestationCIA Attestations | Black Trigram | Compliance Manager
OpenSSF Scorecard≥7.0 score7.2+ across all projectsCIA Score | Black Trigram | Compliance Manager
SBOM GenerationSPDX + CycloneDXAutomated SBOM per releaseGitHub release assets with SBOM attestations
Dependency ReviewZero critical unresolvedDependabot + SCA scanningVulnerability reports in repository
Code SigningSigned releasesGitHub attestation signaturesIntoto provenance files (.intoto.jsonl)

SUPPLY CHAIN ILLUMINATION: SLSA 3 means build provenance is cryptographically verifiable. Can't fake it. Can't social-engineer it. Either you have attestations or you don't.

Vulnerability Disclosure: CRA Annex I § 2.2 Compliance

CRA requires coordinated vulnerability disclosure processes. Each Hack23 project includes standardized SECURITY.md:

  • Private Reporting: GitHub Security Advisories for confidential disclosure
  • Response Timeline: 48h acknowledgment, 7d validation, 30d resolution target
  • Recognition Program: Public acknowledgment (unless anonymity requested)
  • Continuous Support: Latest version maintained with security updates
  • Vulnerability Scope: Authentication bypass, injection attacks, remote code execution, data exposure, cryptographic weaknesses
  • ISMS Integration: All vulnerabilities processed through Vulnerability Management Policy

Public vulnerability disclosure policies:

DISCLOSURE ILLUMINATION: Public vulnerability policies signal mature security practices. Absence of SECURITY.md suggests immature security practices. Transparency attracts responsible disclosure.

ISMS Policy Integration: Systematic Compliance Framework

CRA technical documentation directly mapped to Hack23 ISMS policies:

CRA RequirementISMS PolicyImplementation Evidence
Architecture & DesignInformation Security PolicySECURITY_ARCHITECTURE.md in each project
Asset ManagementAsset RegisterAll components documented with CIA classification
Encryption StandardsCryptography PolicyAES-256, TLS 1.3, KMS-managed keys
Access ControlAccess Control PolicyMFA enforcement, least privilege, audit logging
Change ManagementChange ManagementAutomated CI/CD with security gates
Incident ResponseIncident Response PlanClassification-driven SLAs, 4hr critical response
Network SecurityNetwork Security PolicyAWS GuardDuty, Security Hub, VPC isolation
Data ProtectionData Classification PolicyCIA+ framework with Porter's Five Forces

INTEGRATION ILLUMINATION: CRA documentation isn't separate bureaucracy—it's systematic integration with operational security framework. One policy, multiple compliance applications.

Conclusion: Compliance Through Operational Excellence

The Cyber Resilience Act demands documentation. Smart organizations already had it.

Hack23 demonstrates CRA conformity assessment through three complete implementations with public evidence: SLSA 3 attestations, OpenSSF Scorecard 7.2+, complete SBOM, systematic risk assessment, ISMS policy integration. This isn't last-minute scrambling—it's operational excellence documented systematically.

Brussels weaponized compliance. We weaponized documentation.

Our CRA Conformity Assessment Process template enables repeatable conformity documentation. All evidence cryptographically verifiable through GitHub attestations. All ISMS policies publicly available. All threat models documented.

Security through transparency beats security through hope.

FINAL ILLUMINATION: CRA exists because market forces failed to incentivize security. Brussels created regulatory consequences. Organizations with systematic security practices win. Organizations with ad-hoc security theater scramble. Choose wisely.