You’re in good company

A few of the companies we’ve worked with.

Found late, fixed slowly

Security is often checked once, near the end: a scan before launch, or a penetration test once a year. The findings arrive as a long report, compete with new features for time, and wait. Meanwhile the code keeps changing, so do the open-source packages underneath it, and more of it is written with AI assistants. A problem found months after it was written takes longer to understand, and every change built on top of it makes the fix riskier.

Security at every step

We add security to the way your software is already designed, written and released, so each problem is caught where it starts.

Where does the problem start?

{{ say }}

  1. Design

    Caught here

    • Threat modelling

      Before a feature is built, we work through how it could be misused with your team, and agree the controls it needs.

  2. Code

    Caught here

    • Secure code review

      Every change reviewed for security, by people and by automated checks, with safe patterns your developers can reuse.

    • Secrets out of code

      Passwords and keys left out of the source, with a check that spots one written in by mistake, so it can be replaced.

    • Code written with AI

      Code from AI assistants goes through the same review and checks as any other code.

  3. Packages

    Caught here

    • Open-source packages

      Each package checked for known vulnerabilities and licence terms, kept up to date, with clear rules for adding new ones.

  4. Build

    Caught here

    • Signed, traceable builds

      Builds made only in your pipeline and signed, with a record of how each was made, so what runs in production is what you reviewed.

  5. Test

    Caught here

    • Tests on a running build

      Each release tested for common weaknesses before it goes live, with a penetration test when the risk calls for one.

  6. Fix

    Caught here

    • Fixes in your code

      Findings from scans, tests and researchers ranked by real risk, fixed in order, and each given a test so it stays fixed.

Hosting, access and cloud settings: Cloud, DevOps & Security

Know what’s in every release

Every application runs on code its team didn’t write: open-source packages, and the packages they depend on in turn. A software bill of materials (SBOM) lists the components in a release and their versions. When a new vulnerability is announced, “are we affected?” becomes a quick search rather than an investigation. We produce one for each release, keep it with the release, and check it against new advisories.

When someone reports a problem

Someone outside your company may find a vulnerability and want to tell you. Make that easy: a published policy, a security.txt file on your site that says where to write, and a process to confirm the problem, fix it and tell the people affected. Reports then reach the right people, not an unread inbox or social media.

example.com/.well-known/security.txt
Contact:
mailto:security@example.comRequired
Expires:
2027-09-30T23:00:00.000ZRequired
Policy:
https://example.com/security-policy
Preferred-Languages:
en
A security.txt file in the format RFC 9116 sets out, with example values. Contact and Expires are the two fields it requires; the date should be less than a year away, and the file is renewed before it passes.

If you sell software in the EU

The EU Cyber Resilience Act sets security requirements for products with digital elements sold in the EU, software and connected hardware alike.

Since

11 September 2026

Manufacturers must report actively exploited vulnerabilities and severe incidents that affect their products’ security, with an early warning within 24 hours of becoming aware and a full notification within 72 hours.

  1. Early warningWithin 24 hours of becoming aware
  2. Full notificationWithin 72 hours
  3. Final reportNo later than 14 days after a corrective measure is available, for an actively exploited vulnerability; within a month from the 72-hour notification, for a severe incident

Reports go through ENISA’s Single Reporting Platform.

From

11 December 2027

The main obligations apply, including how vulnerabilities are handled and documented.

Whether the Act covers your product is a question for your legal advisers. Once you know, we build what it asks for into your releases: an SBOM, a way to handle and report vulnerabilities, and security updates.

Evidence that builds itself

Customers send security questionnaires, and auditors ask for proof. When the checks run in your pipeline, the proof already exists: each change’s review, the scan results, the SBOM for each release and every fix with its date. It supports audits such as SOC 2 and ISO 27001, and makes questionnaires quicker to answer.

Start with a review

We start with a short review of your code, your pipeline and your dependencies, and the risks that matter most for your product. You get a ranked list of what to fix, and we fix the first items ourselves, along with the checks that keep them fixed. What the review finds decides what comes next.

A ranked list
Of what to fix, with the reason for each
The first fixes
Made in your code, by our engineers
The checks
Added to your pipeline, so they stay fixed

Work with us as a dedicated team, on a fixed price project or a mix of both. Compare engagement models

FindingFirst to fix
What
Invoices open without a check on who is asking
Where
Invoice download, where an invoice is found by its id
Why it matters
One customer could open another customer’s invoice
The fix
Check the invoice belongs to the person asking
The test
Ask for another customer’s invoice, and expect a refusal
An example finding from the review, written in full: what it is, where it is, why it matters, the fix and the test that keeps it fixed.

Questions worth asking

Isn’t a yearly penetration test enough?
It’s a useful check, but it shows one moment. Checks in every release cover the changes in between, so the test can look for the harder problems instead of the basics.
Will automated scanners find everything?
No. They’re good at known patterns and known vulnerable packages, and they raise false alarms. Design flaws and broken permissions need someone who understands the product.
Do we need an SBOM?
If your customers ask for one, you’ll need one, and the Cyber Resilience Act asks for one from December 2027 for the products it covers. Even without that, it’s a quick way to know whether a new vulnerability affects you.
Is code from AI assistants less secure?
It can contain the same mistakes as any code, and it’s easy to accept without reading closely. So it gets the same review and checks.
Can you work alongside our developers?
Yes. We add the checks to your pipeline, review with your team and leave standards they can keep using after we’ve gone.
Can you guarantee our software is secure?
No one can. We lower the risk, find problems sooner and keep a record of what was checked and fixed.
We have an active incident. Can you help?
Tell us what’s happening through Urgent help, and we’ll confirm whether we can help.

Let’s secure it better

Tell us about your software and what’s on your mind. We’ll look at where the risks are and suggest a sensible first step.

Thanks, we’ll be in touch soon.

{{ ctaStatus }}