Security inside development, not just at the end

Who it's for

For companies that handle customer data or money and only look at security when something happens.

What it solves

• An access key ended up in the repository, and nobody knows since when.
• A known flaw in a library sits in the system for months without anyone noticing.
• A large customer sent a security questionnaire, and nobody knows how to answer it.
• Security only comes up after an incident, never while a feature is being designed.

What we do

Threat modelling

For each sensitive feature, what could go wrong, who would gain from it and how to stop it.

Secure code review

Review focused on authentication, authorisation, input validation and the handling of sensitive data.

Dependencies and secrets

Scanning for libraries with known flaws and for keys left in the code or its history.

Checks in the pipeline

Static and dependency analysis on every change, inside the release pipeline.

Open references

OWASP guides serve as the reference for the controls; this is not a statement of compliance.

Fixing findings

Findings from third-party penetration tests, prioritised and fixed with a regression test.

What you get

• A threat model for the sensitive features
• Code, dependency and secret checks running in the pipeline
• A security review report, with priorities and suggested fixes
• A remediation plan for the findings, followed through to closure
• Technical answers for your customers' security questionnaires

How we do it

1. Risk map

   Sensitive data, entry points and who can do what in the system.

2. Threat modelling

   Short sessions with the team on the highest-risk features.

3. Automated checks

   The analyses join the pipeline, first warning, then blocking what is serious.

4. Fixing

   Findings prioritised by risk and fixed alongside normal work.

5. Independent test

   Where appropriate, a third-party penetration test checks the result.

Technology examples

• OWASP ASVS
• Semgrep
• Trivy
• Gitleaks
• Dependabot
• ZAP