Offensive & Application Security
Secure code review and DevSecOps
Security review of your source code, plus practical help building security checks into your CI/CD pipeline so issues are caught before release.
Key areas covered
- Approach
- Automated SAST and dependency analysis, plus targeted manual review
- Languages
- Confirmed during scoping, based on your stack and frameworks
- Reference standards
- OWASP ASVS, OWASP Code Review Guide, CWE Top 25
- You receive
- Findings with file and line references, fix guidance and a developer walkthrough
Overview
About secure code review and DevSecOps
A secure code review examines your application’s source code for security flaws. It finds issues that a penetration test can miss, such as weak cryptography, hidden administrative paths or vulnerable code that testers never reached, and points developers to the exact lines that need to change.
We combine static application security testing (SAST) and dependency analysis with manual review of the code that matters most: authentication, authorisation, data access, input handling and secrets. It works well on its own or alongside web application and API testing.
A typical starting point
You want security flaws found in the code itself, and caught automatically in your pipeline in future.
The security problem
Flaws that are easiest to find in the code
Missing or inconsistent authorisation checks
One endpoint without the right check can expose data that every other endpoint protects.
Unsafe handling of input
Input passed to queries, commands, templates or file paths without validation or safe APIs.
Secrets in source code
API keys, passwords and tokens committed to repositories, where they spread to every copy and backup.
Risky dependencies and pipelines
Outdated libraries with known vulnerabilities, and CI/CD pipelines that can be abused to ship malicious code.
What’s covered
What we review in your code and pipeline
Area 01
Access and identity
- Authentication, password handling and session management
- Authorisation checks on every sensitive action and data query
- Multi-tenant data isolation
Area 02
Input and output
- Input validation and output encoding
- Injection sinks: SQL, OS commands, templates, deserialisation
- File handling and server-side request patterns
Area 03
Secrets and cryptography
- Hardcoded credentials, keys and tokens
- Algorithm choice, key handling and random number generation
Area 04
Errors, logging and data
- Error handling that leaks internal details
- Sensitive data written to logs
- Personal data handling compared with what you intend
Area 05
DevSecOps and pipeline security
- Review of CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) for exposed secrets and excessive permissions
- Practical integration of SAST, dependency scanning and secret scanning, tuned to keep noise low
- Software bill of materials (SBOM) and build integrity practices
- Branch protection and code review controls
Area 06
Dependencies and configuration
- Third-party libraries with known vulnerabilities (software composition analysis)
- Framework security settings, and configuration and infrastructure-as-code files in the repository
Our approach
How a secure code review is carried out
Step 1: Scoping
We agree repositories, branch or commit, languages, frameworks, size and the features that matter most.
Step 2: Threat-led prioritisation
We identify the high-risk components and data flows, so review time goes where it counts.
Step 3: Automated analysis
SAST and dependency scanning with established tools such as Semgrep and OWASP Dependency-Check.
Step 4: Manual review and triage
We review the prioritised code by hand and confirm or discard automated results, so you only receive real issues.
Step 5: Reporting and walkthrough
Findings are documented with file and line references and discussed with your developers.
Step 6: Fix verification (optional)
We review the changes made for each finding and confirm they resolve it.
Standards and references we work to
- OWASP ASVS
- Application Security Verification Standard: the requirements code is checked against.
- OWASP Code Review Guide
- Guidance on reviewing code for security.
- CWE Top 25
- MITRE’s list of the most dangerous software weaknesses, used to classify findings.
- OWASP Top 10
- Risk categories used when reporting web application findings.
What you receive
What you receive from a code review
Summary of findings
Overall assessment, the most significant issues and recurring patterns across the codebase.
Detailed findings
Each issue with file and line references, CWE classification, severity, explanation of the risk and recommended fix, with example code where it helps.
Dependency report
Vulnerable third-party components and the versions that fix them.
Developer walkthrough
A session with your team covering findings and secure coding patterns for your stack.
Fix verification
If in scope, confirmation that fixes resolve each finding.
Sample finding
SQL injection in the public report export
src/reports/export.ts, line 142
CWE-89 SQL Injection; OWASP ASVS 4.0.3 V5.3.4
- What we found
- The sort parameter of the unauthenticated export endpoint is concatenated directly into an SQL query.
- Evidence
- Line 142 builds the ORDER BY clause from request input. In the test environment we confirmed a crafted sort value reads data from other tables. Code excerpt and request attached.
- Business impact
- An attacker could read or alter data across the whole database, including customer records and password hashes.
- Fix
- Use parameterised queries, map sort options to an allow-list of column names, and add a static analysis rule to the CI pipeline that blocks string-built SQL.
- Status
- OpenFixed, verified at retest
Good to know
Automated scanning alone produces noise
SAST tools are valuable, but on their own they produce many false positives and miss flaws that depend on business context, especially missing authorisation checks. Manual triage and review turn a long tool output into a short list of real, fixable issues.
Before we start
What we need to review your code
- Read access to the repository, or a source archive, with the branch or commit to review.
- Build instructions or a short architecture walkthrough.
- A developer contact for questions.
- Agreed source code handling terms: where it is stored, who can access it, and deletion at the end of the engagement.
Not sure you have everything?
We confirm exactly what secure code review and DevSecOps needs from your side during the scoping call, before any work is agreed.
Book a scoping callFAQ
Questions about secure code review and DevSecOps
Still have a question?
Ask about scope, timing or cost for secure code review and DevSecOps, even if you are not ready to commission work yet.
Contact our teamIs code review better than penetration testing?
They complement each other. Penetration testing shows what can be exploited in the running application. Code review finds flaws testers may not reach and pinpoints exactly where to fix them. For high-risk applications, doing both gives the most complete picture.
Can you review our entire codebase?
We can, but for large codebases a prioritised review is usually far better value. We focus manual effort on high-risk components and use automated analysis for breadth across the rest.
Do you need access to our CI/CD pipeline?
No. We only need read access to the code. If you want, we can recommend how to integrate SAST and dependency scanning into your pipeline afterwards, so issues are caught earlier.
How do you protect our source code?
Code handling is agreed in writing before the engagement: who can access it, where it is stored and when it is deleted. We can sign an NDA first, and we can review code in your environment if you prefer it never leaves your control.
Related services
Often combined with secure code review and DevSecOps
Talk to us about code review and DevSecOps
Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for secure code review and DevSecOps.