Code Review

If your business depends on software you didn't build and can't fully vouch for, a security review tells you what's in it before it becomes a problem.

Code review
Home    Services    Code Review

Why use Intuitive IT to review your code?

Find out what's actually in it

A structured audit of the codebase and its live configuration, so the things no one currently accountable knows about stop being unknowns.

A report you can act on

Findings prioritised by what's genuinely urgent, what can wait and what's already fine, grouped by who needs to do the fixing. Your own developer or IT provider can pick up the work, or we can quote for it.

Judgment, not just output

Every finding is reviewed by an experienced developer who has operated the platforms involved and stands behind the result.

Schedule a call to talk about a review

It works. But is it safe to run a business on?

"It works" and "it's safe to run a business on" are two different bars. Code gets built to meet a deadline, satisfy a requirement or prove an idea. Once it's running and nothing is visibly broken, nobody goes back to check the second bar was ever met.

That applies to a plugin bought years ago, an internal tool built by a developer who has since left, a contractor's handover, and code your team wrote under pressure. The system does its job. The questions a security review asks were simply never asked.

Best timed before: launch, a new customer contract, an audit, or the point the system starts touching real customer data.

What slips through, even in code that runs perfectly

  1. API keys and credentials hardcoded or over-privileged
  2. Client-side only authorisation checks, allowing API bypass
  3. Payments, email and CRM connected with a personal or over-privileged account instead of a scoped one
  4. No audit logs for sensitive data access
  5. Default, insecure hosting and database configurations

None of these shows up in a demo. All of them show up in an incident.

Programming

A security review closes that gap

Intuitive IT's Code Security Review pairs a structured audit of the codebase with an experienced developer's judgment. It checks not just what the code does, but what it's actually exposed to: live platform configuration, third-party credential scope, and real-world attack paths that only show up once you look past the source.

You get back a clear, prioritized report: what's genuinely urgent, what can wait, and what's already fine. It is built to be handed straight to whoever does the fixing, whether that's your existing developer, your IT provider, or Intuitive IT itself.

Best timed before: inheriting legacy systems, expanding customer data exposure, or when team ownership of code is uncertain.

Schedule a call to talk about a review

How a review runs

The AI does the systematic legwork at a speed and consistency no human matches. The experienced developer supplies the judgment, the live-system access and the accountability.

Step 01

Scope and brief

We agree what's in scope, what's explicitly out of scope, who the report is for and any deadline. This is a security review, not a general code-quality audit, so we don't pad findings with style and maintainability nitpicks.

Step 02

The code-based audit

Working from your full repository including history, we run a fixed methodology across architecture, data storage, secrets handling, authentication and access control logic, and hardening.

Step 03

Live-system verification, where available

Network exposure, IP allowlisting, third-party credential scoping and audit logging cannot be confirmed from code, because documentation and code drift from what's actually running. Platform access is optional: if we have it, we work through the relevant consoles with you and confirm these directly. If we don't, they are reported as unverified concerns for you to check.

Step 04

Developer sanity check

Does the severity match realistic likelihood and blast radius? Is there context that changes the picture, such as a network boundary, a compensating control or an internal-only deployment? Is the recommendation implementable for your team and stack?

Step 05

Report, sign-off and delivery

Findings are consolidated, grouped by who needs to act and calibrated for your audience, technical or executive. Anything client-facing gets a second senior reviewer before delivery, particularly for critical and high findings.

Step 06

After delivery

The review ends at the report. We recommend remediation timelines by severity, with short follow-up dates on the urgent items, and whoever does the work can act on them. Both remediation and a re-review against the same findings are separate pieces of work, quoted once you know what needs doing.

Schedule a call to talk about a review

What you get back

Prioritised findings

Each one severity-rated and justified in the text by likelihood and blast radius, not simply asserted.

Grouped by who acts

Code, third-party console, infrastructure, or a process decision, so you can route the work immediately.

An executive summary

Readable by your least technical stakeholder, with a clear next step and no unexplained jargon.

What's already fine

Genuine positive observations. A report that reads as purely negative is less credible and less useful for prioritisation.

A clear path to the fix

The review gives you the full picture first, so remediation can be scoped and costed against what's actually there. Your own developer or IT provider can pick the work up directly, and we're glad to quote for it if you'd prefer we handled it.

Commercial in confidence

The report contains no secret values or credentials, but it does describe vulnerabilities in your system. It is flagged commercial in confidence and should be handled accordingly.

Public code sample reports

Reviews of publicly available open-source packages, run exactly the way a client review is run. No client code appears in these. They are published so you can see the method and the format before you commission anything.

Yoast SEO

Version 28.6-RC1 · reviewed 17 September 2026
Commit 6530cf4

A free WordPress plugin that improves how a site performs in search engines and how readable its content is, installed on millions of sites. Chosen because it is well known, mature and actively maintained.

It shows what the report looks like when a codebase is already in good shape: how findings are rated when none of them are critical, where the real risk sits once severity is judged against realistic exploitability, and what we would recommend acting on first.

Read the report

Newtonsoft.Json

Version 12.0.3 · reviewed September 2026
Tagged commit 7c3d7f8

The most widely used JSON library in the .NET ecosystem, still present in a great many production applications. We deliberately reviewed an older release rather than the current one so the review would cover a version with a published CVE against it.

It shows what the report looks like when a known vulnerability is in scope: how a public advisory is confirmed against the code, what it means for a system actually running that version, and where upgrading is the answer versus where it isn't.

Read the report

Apache Log4j

Version 2.14.0 · reviewed September 2026
Tagged release rel/2.14.0

The Java logging library at the centre of Log4Shell, one of the most consequential vulnerabilities ever disclosed. We reviewed the version that shipped immediately before the fix, so the flaw is present in the code under review.

It shows what the report looks like against a known critical: how a severe finding is evidenced and written up, what a realistic exploitation path through a real system looks like, and what the remediation advice is beyond "upgrade".

Read the report

We don't let the AI do the review

An AI agent will sometimes flag a finding that is technically correct but contextually wrong, such as something marked unauthenticated that is actually protected by a network boundary it cannot see. It will occasionally state something plausible but incorrect about how a framework or platform behaves. And it can over- or under-state severity depending on how a vulnerability class is usually discussed online, rather than how exploitable it is in your system.

That is why reviews here are run by senior developers only, who independently operate the consoles the AI cannot reach and challenge every finding before it reaches you. The name and judgment behind the report are ours.

Schedule a call to talk about a review
Monitoring

What we need from you

  • Codebase access: the full repository, including history rather than just the current branch.
  • Live platform access, optional: cloud consoles, database admin, third-party dashboards for payments, email and auth, and your CI/CD. Where we have access we verify those concerns directly; where we don't, they go into the report as unverified items for you to check.
  • A scoping conversation: what's in, what's out, who reads the report and when you need it.

Draft findings are kept in a private document outside your repository throughout, so material referencing unfixed vulnerabilities never sits somewhere it could leak.

Schedule a call to talk about your project
product iteration

Want to discuss a code review?

Get in touch for a no obligation discussion