Cybersecurity · Application security
Security checks built into development, not added afterwards
We build threat modelling, code and dependency checks, API authorisation and edge protection into your delivery process. A release that does not meet the agreed standard does not go out. What you get is a working pipeline, not a report.
Where this starts
Most security issues are found too late to be cheap to fix
A vulnerability found in a customer’s penetration test costs far more than the same issue found while the code was being written. The fix itself is usually the same. The extra cost comes from pulling a release, telling a customer, and having an open issue on your next security questionnaire. Most teams already have security tools. What they lack is a point in the process where a finding actually stops a release.
What we usually find
- Security scanners that run, but whose findings nobody owns and which never stop a build
- APIs that check who a user is but not what they are allowed to see, so changing an ID in a request returns another customer’s record
- Third-party dependencies chosen at the start of the project and never reviewed since
- Passwords and keys stored in configuration files, code history, pipeline logs or container images
- A web application firewall in front of production that only monitors traffic, and that nobody has configured
- Mobile apps released with debug features, detailed logging and no protection against intercepted connections
Our position
A security check that cannot stop a release is only advice. We would rather put in three checks that block a bad release than thirty that only issue warnings.
What the work covers
Everything an attacker can reach, not just the code
Application security is no longer only about source code. Attackers target the API, the permission model, third-party dependencies, the build system and the network edge. All of these need to be secured together.
Threat modelling that produces real tasks
We run a working session for each important service or feature, looking at how data moves and where trust changes. The result is a set of tickets with owners and acceptance criteria, rather than a diagram that is filed and forgotten.
API security
We test permissions for every individual record and field, not just for each endpoint. The most commonly exploited API weakness is letting one user access another user’s records, and automated scanners cannot detect it because they do not know who owns what. We also add input validation, rate limits and tests that confirm one customer cannot reach another customer’s data.
Supply chain and pipeline checks
We add code analysis, dependency and licence scanning, detection of exposed secrets, and a software bill of materials for every build. Findings above an agreed severity block the release, and there is a documented process for exceptions. A check that people work around is worse than no check at all.
Edge protection
We write firewall rules based on your own traffic and switch them from monitoring to blocking. We protect sign-in and payment pages against bots and stolen-password attacks, and we test your protection against denial-of-service attacks rather than assuming it works.
Container security
We use minimal base images that do not run with administrator rights. Every layer is scanned for known vulnerabilities and hidden secrets, and every image is signed when it is built, so you can verify exactly what reaches production. Securing the cluster that runs these containers is covered under network and cloud security.
Mobile application security
We assess mobile apps against the OWASP mobile security standard. This covers protection against intercepted connections, secure storage on the device, tamper detection where the risk justifies it, and removing debug features and embedded keys before an app is published.
Testing that ends with a fix
We scope penetration testing according to risk rather than a fixed calendar. We fix each issue alongside the finding and retest to prove the fix works. Not every testing firm will fix what it finds, but we do.
How it stays fixed
The automation is what you are paying for
Anyone can produce a list of findings. The engagement is only worth its fee if the same kinds of problem cannot quietly come back after we leave.
Before a commit
Secret detection runs on the developer’s own machine, so a password or key never reaches the code history. Removing one afterwards is not a simple deletion: every system that trusted it has to be given a new one.
Pull request
Code analysis and dependency checks run only on the change, not the whole codebase. The results are relevant to the change, and reviews stay fast enough that nobody is tempted to skip them.
Build
Images are scanned, a bill of materials is produced and the build is signed. Anything that has not been scanned and signed cannot move to the next environment.
Deploy
Infrastructure definitions are checked against policy, and releases are blocked at the severity levels you agreed. Exceptions have an expiry date and a named owner, and are never granted indefinitely.
Live
Firewall and rate-limit data feeds into the dashboards your engineers already use. A blocked attack is visible to the people who can act on it, not hidden in a console nobody opens.
What you are left with
- A threat model for each service, kept up to date as part of the definition of done
- A pipeline that blocks releases on the findings you agreed should block them
- A bill of materials for every release, which answers much of a customer security questionnaire on its own
- Firewall and rate-limit rules tuned to your traffic and actively blocking attacks
- Minimal, signed container images with no secrets inside
- Runbooks written for, and owned by, the engineers who will be on call
Tell us what you release and how often
We will show you where the checks belong and what they would have blocked in the first month.