Who can change your live product without anyone checking?
We follow a change from a developer’s laptop to your live product, and find who and what could slip something in on the way.
Request a scoping callFree 30-minute scoping call.
Unreviewed code that can use your production keys
A fictional example of what can go wrong here. A related problem appears as CLD-01 in our sample report.
Someone proposes a change
Code nobody has reviewed yet, maybe from someone outside the team, runs in your build.
The build holds production keys
The same build can deploy to production or read your secrets.
Nobody has to approve it
Nothing checks the change was reviewed before those keys are used.
It reaches production
One unreviewed change, or one stolen account, can ship code or copy your secrets.
So we ask: Can code that nobody has approved use your production keys?
For your engineer
.github/workflows/build.yml
on: pull_request_target
jobs:
build:
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- run: npm ci && npm run build
env:
DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}
What we check
The questions we start from. We agree the final list with you on the scoping call.
- Who can push code to which repositories, and which changes need a review?
- What can your build reach, and whose code will it run?
- Which free packages and build tools do your releases depend on?
- What could one developer or contractor account, token or laptop reach?
Best done when the team grows or contractors get access.
What you get, and what it costs
Fixed fee for the agreed scope, quoted before work starts.
We quote it after the scoping call, once we know what’s in. If the scope grows later, we price the extra before we start it.
Included
- The assessment of the systems we agree
- A findings report with the evidence for each issue
- What to fix first, and how to check each fix
- A walkthrough call with your engineers
- One round of retesting after your fixes
- The repository, pipeline and access changes, in order
Not included: Making the fixes (your engineers do that), a compliance certificate and anything outside the agreed scope. Quoted separately: Further retests after the first and extra scope added once work has started.
Before you enquire
What people ask us most. Wondering whether a pentest would do? Is a VAPT enough?
What do you need from us?
Read-only access to the repositories and organisation settings in scope, with the pipeline files and approval rules.
Where do you stop?
We cover the repositories, pipelines and access settings you name. It isn’t a full review of your source code.
Is this a penetration test?
No. We review repository, pipeline and access settings. If you want hands-on testing too, we’ll put that in the scope.
Will the changes slow our releases down?
We put the most important changes first, and talk through the effect on your releases with your team before we hand them over.
How do you handle confidential material?
Send an outline first and leave out passwords and customer data. We only ask for anything sensitive once we’ve agreed the scope and a safe way to share it.
If nobody can say who can push to production, start here
Which source control and CI/CD tools do you use, and who can deploy today?
What happens next
Sending an enquiry doesn’t commit you to anything. About the team