Secure code review

ISO/IEC 27001:2022 does not name code review as a mandatory activity, but two Annex A controls cover the ground. Control A.8.28, Secure coding, asks the organization to apply secure coding principles to its software. Control A.8.29, Security testing in development and acceptance, asks for security testing processes to be defined and carried out during development. Auditors typically look for a documented secure coding standard, defined review or testing steps in the development life cycle, records showing that findings were tracked to closure, and evidence that the process runs for real releases. A code review engagement can supply the test records and findings register, while your own team keeps the standard and the process running. The control wording is in ISO/IEC 27002:2022, which gives implementation guidance. Confirm the exact expectations with your certification body.

DORA Article 25(1) lists source code reviews among the appropriate tests in a digital operational resilience testing programme, but only where feasible. The same list includes vulnerability assessments, open source analyses and penetration testing. Supervisors and auditors generally expect a financial entity to justify its test mix, so the testing programme should record which tests were chosen for which systems, why, and what was excluded and why. For code reviews, evidence usually includes the defined scope of the ICT systems covered, the reviewer's method, the findings with severity and status, and proof that critical issues were fixed and retested. Read the article in the Regulation (EU) 2022/2554 text on EUR-Lex and confirm with your competent authority how it applies to your entity and your ICT third-party arrangements.

The CMMC Assessment Guide for Level 2 says that custom-developed software may need penetration testing or source code scanning when assessors examine vulnerability scanning requirement 3.11.2. The word "may" matters: the assessment depends on what systems are in scope, how they are built, and what the organization can show. Assessors typically look for a defined scanning or testing process, the tools or methods used, the scope of applications covered, dated results, and records of remediation. Where custom applications process controlled unclassified information, expect questions about who reviewed the code and how findings were tracked. Requirement text and assessment objectives are described in NIST SP 800-171A. Confirm with your C3PAO or sponsoring agency which applications they expect to see tested.

OWASP ASVS 5.0.0 notes that verifying many Level 2 and Level 3 requirements needs more than black box testing. Assessors may need documentation, source code, configuration and access to the development team. For a Level 2 or Level 3 verification, plan to provide architecture and design documents, the relevant repositories with read access, build and configuration files, and named developers who can explain authentication flows, authorization decisions and cryptographic choices. The reviewer then checks each requirement against the code and the evidence, and records where a requirement is met, not met or not applicable. Without source access, some requirements cannot be verified at all, so the verification report should say so. The standard is available in the ASVS 5.0.0 source on GitHub. Agree the access model in writing before testing starts.

Auditors want to see that a review happened, what it covered, what it found, and what was done about it. Across the frameworks above, the common evidence set includes:

• A written scope listing applications, repositories, branches and the release version reviewed
• The method used, including manual review, tool-assisted analysis and the rules or standard applied
• A findings register with severity, affected file or component, status and owner
• Retest results showing that fixes were verified
• Records that the review was repeated on a defined basis or after significant change

DeployOpen prepares systems, controls and evidence for compliance assessments, and can structure review records to match what your assessor asks for. Auditors and certification bodies issue the conclusions on whether a control is effective. Ask your assessor early which evidence format they accept.

Usually not on its own. A penetration test exercises the running application from outside, so it cannot confirm that authorization checks, cryptographic choices or input handling are correct across every code path. Frameworks that refer to source code review, including DORA and ASVS Level 2 and Level 3, expect access to the code or the team that wrote it. A penetration test and a code review answer different questions, and many programmes run both. Confirm with each assessor whether they accept a penetration test for a given requirement, and document the reason for the test mix in your testing programme.

The organization being assessed remains responsible for compliance. The code review provider delivers testing, findings and records under a written scope. An independent auditor, assessor or certification body decides whether the framework's requirements are met. DeployOpen prepares systems, controls and evidence for compliance assessments, and runs security testing, but it does not issue audit reports, attestations or certifications. Your team should own the secure coding standard, the remediation workflow and the decision about accepted risk. Clarify these responsibilities in the statement of work so that each party knows which evidence it produces and who signs off.

Start with the obligation, not the framework name. Identify which regulator, customer contract, certification or scheme requires the testing, and ask that party which systems and test types they expect. For a regulated financial entity, the question goes to the supervisor or the entity's compliance function. For a US defense contractor, it goes to the C3PAO or sponsoring agency. For a certification, it goes to the certification body. Write down the answers, including which applications are in scope and which evidence is required. Those answers drive the review scope, the access you need to provide and the timing of each report, so settle them before choosing a provider.

Cost depends mainly on how much code is in scope, how many languages and frameworks it uses, how much of the authentication, authorization, input handling and cryptography logic must be read by hand, and how many review rounds the findings require. DeployOpen does not publish a price list, so a quote follows from a written scope. Before scoping, you can gather the approximate repository count, lines of code per repository, languages, framework versions, and whether a threat model or architecture document exists. Ask any provider for a quote that lists the review units, the people and hours by role, the tools used, the retest allowance and what is excluded. Most of the cost is one-time for the review itself. Retesting and any follow-on retainer for continuous code review recur, and you should confirm how each is priced.

The timeline is set by the size of the agreed scope, the complexity of the security-relevant code, how quickly your developers answer questions, and how many fix and retest cycles are planned. Engagements are fixed-scope, so scope, deliverables and dates are agreed in writing before work starts. Ask for a schedule that separates access setup, the review itself, the draft findings walkthrough, the final report and the retest window. Delays most often come from missing build instructions, unavailable architecture documents, or a late decision on which modules are in scope. If a compliance deadline applies, state it at scoping so the start date and the report date can be checked against it.

A secure code review needs read access to the relevant repositories, a branch or tag that matches the version in production, and a named technical contact who can answer design questions quickly. The reviewer also needs working build and test instructions, configuration files with secrets removed, architecture diagrams, data flow notes, and a list of trust boundaries such as identity providers, payment services and third-party APIs. Plan roughly a short kickoff session and then regular question windows during the review. Developers should expect to explain intended behavior for authorization rules and cryptographic choices, because these are often the hardest to judge from code alone. Confirm what access method, logging and data handling rules apply to source code in your environment before the review begins.

Your team can run static analysis and software composition tools, and these catch a useful class of known patterns, such as unsafe function calls, hardcoded secrets and vulnerable dependency versions. They do not reliably judge whether an authorization check is applied to every route, whether a business rule can be abused across steps, or whether a cryptographic design fits the threat model. Those judgments need a reviewer who reads the code in context. A practical split is to run scanners continuously in your pipeline, then commission a manual review for the highest-risk modules and compare its findings with scanner output. Ask any provider how it treats scanner results, including false positives and whether it reproduces each issue before reporting it.

A secure code review examines the source to find the cause of weaknesses, including logic errors that never appear in normal traffic. A penetration test examines the running system from outside or from a defined position to show what an attacker could reach and chain together. The two answer different questions, so they complement each other. Code review is strongest for authorization logic, input handling and cryptographic use, while penetration testing confirms how those weaknesses behave in deployed configuration and infrastructure. Many organizations commission both for a major release or a high-risk application, and sequence the code review first so the penetration test focuses on the live system. Your choice depends on the application, the threat model and what your customers or regulators expect.

No single review satisfies a framework by itself. DORA Article 25(1) lists source code reviews where feasible among the appropriate tests in a digital operational resilience testing programme, alongside vulnerability assessments, open source analyses and penetration testing (Regulation (EU) 2022/2554). The CMMC Assessment Guide Level 2 says custom-developed software may need penetration testing or source code scanning when assessing requirement 3.11.2. ISO/IEC 27001:2022 control A.8.29 expects security testing defined within the development life cycle, and A.8.28 covers secure coding. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports or certifications. Confirm with your assessor which tests and evidence they expect, and whether they accept a code review as one of several tests.

After the report, your developers fix findings in the codebase, and the provider verifies each fix through a retest against the original finding. Confirm in writing how many retest rounds the scope includes, how the retest is documented, and how findings that are accepted as risk or disputed are recorded. A useful report gives each finding a location in the code, the affected trust boundary, the reason it matters, a reproduction or reasoning trail, and a recommended fix. Ask whether the output maps to recognized references such as OWASP ASVS requirements, so your auditor can trace fixes to controls. For ongoing assurance, a retainer can cover periodic review of changed modules, but it is a separate agreement from the original review.