Skip to content
Unmesha Technologies, security assessments

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 free callWhat you get

Free 30-minute call.

A typical SaaS product. Free packages come in, and the pipeline ships them with your code. It uses a deploy credential to do it.

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.

  1. Someone proposes a change

    Code nobody has reviewed yet, maybe from someone outside the team, runs in your build.

  2. The build holds production keys

    The same build can deploy to production or read your secrets.

  3. Nobody has to approve it

    Nothing checks the change was reviewed before those keys are used.

  4. 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 call.

Best done when the team grows or contractors get access.

  • 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?

What you get, and what it costs

A report with the evidence for each issue, what to fix first, and one round of retesting. See what a report looks like.

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

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

  1. We reply within one working day. We set up the call, and you meet the people who’d do the work.
  2. We send a proposal with the scope, the timing and a fixed fee.
  3. Work starts when you say go.

Sending an enquiry doesn’t commit you to anything. About the team

Request a free call

Send a short outline of what you want checked and any deadline.

Email Unmesha

Please leave out passwords and customer data. How we handle enquiry information.