Secure coding supports CRA readiness when it is repeatable, stack-specific and connected to product risk. The strongest approach combines a documented coding baseline with peer review, automated analysis, dependency controls, secret scanning and negative tests, then retains release evidence showing those controls were actually used.
Secure Coding Supports CRA Outcomes Rather Than Replacing Them
The Cyber Resilience Act does not prescribe one universal secure coding standard or require manufacturers to use a particular programming methodology. Article 13 instead requires products to be designed, developed and produced in accordance with the applicable Annex I cybersecurity requirements and requires the cybersecurity risk assessment to influence development. Secure coding is therefore an implementation practice used to reduce software weaknesses that could undermine those legal outcomes. The coding controls selected should reflect the language, framework, architecture and risks of the product.
- Do not treat secure coding as a separately numbered CRA requirement.
- Connect coding controls to identified product risks.
- Use stack-specific rules rather than generic slogans.
- Retain evidence that the controls were actually used.
Define a Secure Coding Baseline
A secure coding baseline gives developers a consistent set of minimum expectations for the technologies they use. ENISA's Secure by Design and Default Playbook recommends language- and framework-specific rules covering areas such as input handling, authentication checks, error handling, cryptographic usage and logging. The baseline can also prohibit dangerous patterns that repeatedly create vulnerabilities. The objective is not to create a large policy manual. It is to make important security expectations available at the point where developers make implementation decisions.
- Define rules for supported languages and frameworks.
- Document prohibited unsafe patterns.
- Cover authentication and authorisation checks.
- Cover error handling and security logging.
- Review the baseline when technology stacks change.
Validate Inputs and Keep Data Separate From Commands
Input validation is a central secure coding control because many vulnerabilities occur where untrusted data crosses into trusted processing. Product teams should define expected formats, lengths, ranges and structures and reject values outside those expectations where appropriate. Output handling should also match the destination context so untrusted data does not become executable commands or markup. Centralised validation libraries and parameterised interfaces can reduce inconsistent handling across the codebase.
- Define accepted schemas and formats.
- Use allowlists where appropriate.
- Check lengths and ranges.
- Use context-appropriate output encoding.
- Avoid mixing untrusted data with executable commands.
Authentication and Authorisation Checks Need Consistent Patterns
Security architecture may define roles and privileges, but implementation determines whether those rules are actually enforced. Developers should use approved authentication and authorisation patterns rather than implementing access decisions differently in each feature. Sensitive operations should verify the current identity and required privilege on the trusted side of the boundary. Negative tests should confirm that unauthenticated or unauthorised requests are rejected rather than only verifying successful access.
- Use common access-control components.
- Enforce authorisation at trusted boundaries.
- Avoid client-side-only privilege decisions.
- Test unauthorised access paths.
- Review privileged code more closely.
Use Cryptographic Functions Through Approved Interfaces
Developers can undermine good cryptographic architecture through unsafe implementation choices such as disabling certificate verification, using inappropriate primitives, mishandling keys or inventing custom cryptographic schemes. Secure coding standards should identify approved cryptographic libraries and usage patterns for the product. Cryptographic design remains a broader architecture topic, but implementation rules can prevent developers from bypassing the intended security properties.
- Use maintained cryptographic libraries.
- Do not disable certificate or signature verification without controlled justification.
- Avoid custom cryptographic algorithms.
- Protect keys and cryptographic material.
- Review security-sensitive cryptographic changes.
Secrets Should Not Be Embedded in Source Code
API keys, credentials, signing material and other secrets should not be committed to source repositories as ordinary code or configuration. ENISA's playbook specifically highlights secrets controls and secret scanning as part of secure coding practice. Products should use appropriate secret-management or provisioning mechanisms, and development workflows should detect accidental secret commits. If exposure occurs, removing the secret from the repository is not enough; the affected secret should also be rotated or revoked as appropriate.
- Keep secrets out of source code.
- Use secret scanning.
- Use appropriate secret-management mechanisms.
- Restrict access to sensitive credentials.
- Rotate or revoke exposed secrets.
Static Application Security Testing Can Catch Common Defects Early
Static application security testing examines source code or related representations for patterns associated with security weaknesses. ENISA recommends SAST as one useful development control. It can help identify issues such as unsafe data handling, injection patterns or insecure API usage before release. SAST should not be treated as proof that the product is secure. Rules need tuning, findings need triage and high-risk issues need remediation or a documented risk decision.
- Run static application security testing during development or CI.
- Tune rules to the technology stack.
- Triage findings rather than ignoring noisy output.
- Track high-risk findings to remediation or controlled disposition.
- Retain relevant release results.
Software Composition Analysis Covers Third-Party Code Risk
Software composition analysis can identify third-party packages and known vulnerabilities associated with those components. This complements source-code analysis because internally written code and external dependencies create different risk paths. Dependency analysis should identify relevant package versions and feed findings into the product's vulnerability-management process. A dependency alert is not automatically evidence that the product is exploitable, but it should be assessed in the context of the product architecture and use.
- Identify third-party dependencies.
- Track dependency versions.
- Assess known vulnerabilities in product context.
- Remove unused packages where practical.
- Connect dependency findings to remediation workflows.
Peer Review Matters Most for Security-Sensitive Changes
Peer review can identify insecure assumptions that automated tools miss. ENISA highlights review of security-sensitive changes such as authentication, authorisation, cryptography, parsers and external interfaces. Teams can define stronger review expectations for these areas, such as required reviewers or code ownership rules. Review should examine whether the change preserves security requirements and trust boundaries, not only whether the code compiles or follows formatting conventions.
- Identify security-sensitive modules.
- Require appropriate peer review.
- Review authentication and authorisation logic.
- Review parsers, cryptographic changes and external interfaces.
- Record approval through the normal development system.
Negative Tests Verify That Unsafe Behaviour Is Rejected
Positive tests show that intended behaviour works. Negative tests check that prohibited or malformed behaviour fails safely. Useful examples include unauthorised access being denied, invalid update packages being rejected, injection attempts failing, malformed inputs being handled safely and excessive privileges being blocked. ENISA's playbook recommends negative tests for critical endpoints and inputs. These tests help convert secure coding expectations into repeatable verification.
- Test unauthorised access.
- Test malformed and boundary inputs.
- Test invalid signatures or update packages.
- Test injection attempts where relevant.
- Include critical negative tests in regression suites.
Retain Secure Coding Evidence by Release
Secure coding evidence should show that controls were used for the version being released. Useful records can include the secure coding baseline, peer-review history, SAST results, software composition analysis results, secret-scanning results, relevant negative-test results and documented exceptions. The objective is not to archive every development event forever. It is to preserve enough evidence to show how important coding risks were controlled and how unresolved findings were handled.
- Secure coding baseline.
- Peer-review records.
- Static analysis results.
- Software composition analysis results.
- Secret-scanning evidence.
- Negative-test results.
- Documented security exceptions.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.