What you receive
A record of reviewed components and version, findings and practical developer recommendations.
For UK businesses and MSPsSource code security reviews
Source code security reviews
Catch weaknesses at the source.
Fig reviews source code for weaknesses in secrets handling, input handling and access checks. You receive a record of the version and components reviewed, findings linked to code locations where applicable and practical recommendations for developers.
At a glance
Your engagement at a glance
Your team’s part
Your developers confirm intended behaviour, implement fixes and test the changes.
Follow-up arrangements
Dependency analysis, repository history and independent fix review need explicit inclusion.
A clearly defined scope. A code review covers the agreed code and review depth. It does not establish the security of the running environment or guarantee that all weaknesses have been identified.
For understanding weaknesses in source code. A separate penetration test examines how the deployed application behaves. Explore penetration testing.
Start with a scope discussion
We’ll agree a written proposal and obtain authorisation before the assessment begins.
The scope
What do Fig code security reviews cover?
A source code security review, also called a secure code review, examines a specified code version for implementation weaknesses. It gives developers findings tied to the code being reviewed, with scope and depth agreed before work begins.
Secrets and sensitive data
Examine the agreed code for embedded secrets and potentially unsafe handling of sensitive information.
Input handling
Review relevant code paths for unsafe handling of untrusted input and related security weaknesses.
Access checks
Examine authentication and authorisation logic in the agreed scope, including potentially missing or inconsistent access checks.
Assessment detail
What does each part of a source code review contribute?
Source code review connects potential weaknesses to the implementation developers maintain. The useful distinction is between detecting a pattern, understanding its context and establishing that a change fixes the intended behaviour.
| Activity | Contribution | Boundary |
|---|---|---|
| Automated analysis | Flags patterns and potential weaknesses that the selected tools can detect. | Language support and configuration affect coverage; a warning is not automatically a confirmed vulnerability. |
| Contextual code review | Examines relevant code paths, permissions and business rules to understand how a potential issue affects the application. | Review depth and component coverage must be explicit. Reading one component does not establish the security of the whole repository. |
| Developer validation | Confirms intended behaviour, implements changes and tests permitted and denied operations. | Your developers own remediation. A subsequent independent review of the fix needs to be included in the engagement or arranged separately. |
For a precise proposal, identify the languages, framework versions, repository or component sizes and release commit. Specify whether dependency analysis and historical commits are needed. The proposal should name the balance of automated analysis and contextual review, rather than treating a tool report as a complete assessment.
When to book
When to book code security reviews
Before a release or sensitive change
Focus review effort on agreed components such as access control or sensitive data handling. Leave time for developers to investigate and fix findings before release.
When automated findings need context
Discuss a review focused on the implementation and business rules that matter to your application. Automated scanning and contextual review provide different information.
Make remediation easier to assign
Use code-level findings to create development tasks with clear ownership. Record the reviewed version so later changes are not mistaken for assessed code.
Security benefits
Security benefits of code security reviews
Examine how permission checks are implemented
Review the agreed code paths that decide who can perform an action or access information. The implementation needs to match the application’s intended roles and business rules, including checks on the server rather than only in the interface.
Trace untrusted input through sensitive operations
Within the agreed components, examine how data reaches operations such as database queries or file handling. Context matters: a pattern flagged by a tool needs to be understood in its actual code path before selecting a fix.
Identify unsafe secret handling
Look for embedded secrets and risky handling of sensitive information within the reviewed version. Removing a secret from code is only part of the response: the authorised owner may also need to rotate it and assess where it has been used or copied.
Commercial value
The commercial value for your organisation
Turn findings into development work
Code locations, affected behaviour and fix guidance help developers investigate issues without starting from an unexplained scanner warning. Agree review depth so the report provides the context your engineering team needs.
Support important release decisions
A review of agreed high-impact components can inform whether more work is needed before release. Record the assessed commit and subsequent changes so decision-makers understand which version the evidence supports.
Improve future implementation patterns
Where a finding reveals a repeated coding pattern, developers can use it to improve shared helpers and regression coverage. Those improvements require engineering work; reviewing one component does not automatically assess every place that pattern is used.
How it works
Your code security reviews engagement
Define the code scope
Agree repositories, languages, frameworks, components and a specific version or commit. Confirm review depth and exclusions.
Arrange secure access
Agree how source code and supporting documentation will be accessed, handled and retained. Do not send credentials or source code through the general enquiry form.
Examine the implementation
Review the agreed components for issues such as embedded secrets, unsafe input handling and missing access checks. The approach depends on the agreed scope.
Discuss findings with developers
Use relevant code locations, context and practical recommendations to plan fixes. Confirm intended behaviour where a finding depends on business rules.
Track fixes and future changes
Your developers implement changes and test their effects. Agree any follow-up review separately and record which version was checked.
Work is authorised in writing before any assessment begins, and stays within the agreed scope.
Compare approaches
Source code review, SAST or penetration testing?
Related services answer different questions. Confirm which scope you are buying before you compare quotes.
| Approach | What it tells you | Scope to confirm |
|---|---|---|
| Code security review | Examines implementation and context in agreed source code. | Requires code access and a defined version, component list and review depth. |
| Static application security testing (SAST) | Analyses code without running the application; automated tools flag potential weaknesses for investigation. | Useful for repeatable checks; findings still require context and can include false positives. |
| Penetration testing | Investigates the behaviour of an agreed running system. | Can complement code review by examining deployment and runtime behaviour within its scope. |
Illustrative example, not a client case study
An input value becomes part of a database query
- Reviewed component
- Illustrative order-query.pseudo, lines 1–2 in the supplied version. This teaching example does not declare support for a particular language or database.
- Code observation
- An input reference is concatenated into SQL text. Its path into the query matters more than a tool warning alone.
- Fix guidance
- Pass values separately through the database driver’s parameter-binding API. Keep the server-side customer permission check as a separate requirement.
- Developer verification
- Check ordinary references and unexpected input, permitted and denied customer access, and any related query helpers. Record the changed commit.
- Review boundary
- This finding concerns the nominated code path. Dependency analysis, repository history and independent verification of the fix require their own agreed coverage.
Illustrative pseudocode
The first query mixes an input value into SQL text. The second passes that value separately. The exact API depends on your database driver.
// Before: input becomes part of the query text
query("SELECT total FROM orders WHERE reference = '" + reference + "'")
// After: bind the input as a value
query("SELECT total FROM orders WHERE reference = ?", [reference])Parameter binding addresses this input-handling issue. It does not replace authentication or checking that the caller is allowed to access the order.
This is a teaching example of a finding record, not an extract from a customer report or a promise of a particular report template.
Cost and preparation
What affects the scope and cost?
Languages, frameworks, repository size, business-critical components, documentation and review depth determine the quote. A focused review of sensitive code and a broader repository review involve different coverage. Agree dependency analysis, history and follow-up work explicitly.
What to prepare for your enquiry
Provide a technology overview, repository and component list, intended roles and a stable commit or release reference. Agree secure access, confidentiality and retention arrangements before sharing source. Explain which features handle sensitive information or privileged actions.
Plan the engagement around your deadline
Allow for access preparation, the assessment, report delivery and your team’s remediation work. Confirm the delivery format, dates and any follow-up checks in your quote so each team knows when its input is needed.
Questions
Code security reviews questions
Practical answers about scope, cost and what happens next.
Compare all six security servicesWhat are code security reviews?
A source code security review, also called a secure code review, examines a specified code version for implementation weaknesses. It gives developers findings tied to the code being reviewed, with scope and depth agreed before work begins.
Link to this answerDoes a code review replace application penetration testing?
No. Code review examines implementation details, while penetration testing investigates behaviour in a running system within agreed boundaries. The services can complement one another; we agree the approach around your objectives.
Link to this answerWhich languages and frameworks can you review?
Share your technology stack and repository size before booking. We confirm suitability, review depth and available expertise during scoping rather than promising coverage of every language or framework.
Link to this answerIs a code scanner the same as a code security review?
No. Automated scanners identify patterns and potential weaknesses; a contextual review examines implementation details within its scope. We agree the balance of tools and review work before the engagement.
Link to this answerDoes the review include all dependencies and repository history?
Not by default. Software composition analysis (SCA) examines third-party dependencies. It, historical commits, generated code and other third-party components need explicit inclusion in the scope. Static application security testing (SAST) examines code, while runtime testing examines the running application. The report should make the reviewed version and exclusions clear.
Link to this answerIs source code kept confidential during a review?
Source access, confidentiality, permitted tooling and retention arrangements should be agreed before the engagement. Share your contractual or data-handling requirements during scoping. Do not send code or credentials through the general enquiry form.
Link to this answerDoes a clean scanner result mean our code is secure?
No. Automated analysis has coverage limits and may miss context-dependent weaknesses. A code review also has an agreed scope and depth. Neither a clean scanner result nor a review report guarantees that all weaknesses have been identified.
Link to this answerHow much do code security reviews cost?
Languages, frameworks, repository size, business-critical components, documentation and review depth determine the quote. A focused review of sensitive code and a broader repository review involve different coverage. Agree dependency analysis, history and follow-up work explicitly.
Link to this answerDoes this service provide compliance certification?
No. Security testing and reviews can help identify gaps, but certification requires a separate assessment under the relevant scheme. Buying this service does not guarantee certification.
Link to this answerYour next step
Choose the support you need.
Explore a different assessment, manage remediation or prepare for certification.
Related service
Penetration testing
A qualified tester attempts to exploit weaknesses in agreed applications, APIs or networks, with written authorisation. Includes a report, fix guidance and a retest of the findings.
ExploreRelated service
Cloud security reviews
Review AWS, Azure or Google Cloud configurations, including access permissions, exposed storage, account protection and logging.
ExploreSoftware
The Fig platform
Manage compliance gaps, remediation and supporting evidence.
ExploreCertification
Cyber Essentials
Explore certification options for your organisation.
ExploreFurther reading
Further technical guidance
Independent sources that explain the methods and controls behind the review.
Independent guidance
OWASP: secure code review
Explains where contextual code review complements automated analysis and how review findings support remediation.
Accountability
Working with Fig
Work with Fig directly or through your MSP. Your proposal identifies the contracting entity, assessment scope and delivery responsibilities.
The companies
Meet the companies behind Fig
See the entities, licences and people behind the platform and our assessments.
ExploreMSP partners
Security services for MSP partners
Offer these services under your own brand and retain the client relationship.
ExplorePublished evidence
Company details and published evidence
Verify our company details, licences and the claims we make in public.
ExploreContent updated .
Let’s agree the right scope.
Tell us what you need from code security reviews, the systems involved and any deadline. We’ll discuss the options and provide a quote.