Skip to content
Lorendix

Cybersecurity · Application security

Security that runs inside the build, not after it

Threat modelling, code and dependency analysis, API authorisation and edge protection, engineered into delivery so a release either meets the standard or does not ship. The output is a working pipeline, not a report.

Where this starts

Most findings arrive too late to be cheap

A vulnerability found in a customer penetration test costs far more than the same vulnerability found on the branch that introduced it, and the difference is not the fix. It is the release that has to be pulled, the customer who has to be told, and the security questionnaire that now carries an open item. Teams rarely lack security tools. What they lack is a point in the pipeline where a finding actually stops something.

What we usually find

  • Scanners running, with findings nobody owns and no build that fails
  • APIs that authenticate correctly but do not authorise per object, so changing an identifier in a request returns another customer’s record
  • Dependencies pinned once at project start and never reviewed since
  • Secrets in environment files, commit history, pipeline logs or baked into container images
  • A web application firewall sitting in front of production in monitoring mode, tuned by nobody
  • Mobile builds shipping with debug endpoints, verbose logging and no certificate pinning

Our position

A control that cannot fail a build is documentation. We would rather ship three gates that block than thirty checks that warn.

What the work covers

The whole surface, not only the code

Application security stopped being about source code some time ago. The exploitable surface is the API contract, the authorisation model, the dependency tree, the build system and the edge, and it has to be engineered as one thing.

Threat modelling that produces backlog items

A working session per significant service or feature, driven from data flows and trust boundaries. The output is tickets with owners and acceptance criteria, not a diagram that ages quietly in a wiki.

API security

Authorisation tested per object and per field rather than only per endpoint. Broken object level authorisation is the most exploited API weakness in production and it is invisible to a scanner that does not know who owns what. We add schema validation, rate and quota limits, and contract tests that assert one tenant cannot reach another tenant’s data.

Supply chain and pipeline analysis

Static analysis, dependency and licence scanning, secret detection, and a software bill of materials produced per build. Findings are triaged to a severity that blocks, with a documented exception path, because a gate people route around is worse than no gate.

Edge protection

Firewall rules written against your own traffic and moved from monitoring into blocking, bot and credential stuffing defence on authentication and payment routes, and volumetric and application layer denial of service protection that has been tested rather than assumed.

Container security

Minimal base images that run as non-root, every layer scanned for known vulnerabilities and embedded secrets, and each image signed at build so what reaches production can be verified. The cluster that runs them, from admission control to runtime detection, belongs to network and cloud security.

Mobile application security

Assessment against the OWASP mobile verification standard: certificate pinning, secure local storage, tamper and root detection where the risk justifies the friction, and removal of debug surfaces and embedded keys before a build reaches a store.

Testing that closes rather than reports

Penetration testing scoped to the risk rather than the calendar, with remediation engineered alongside the finding and a retest that proves it. We are as willing to fix as to find, which is not true of every firm that will test for you.

How it stays fixed

The automation is the deliverable

Anyone can produce a list of findings. The engagement is only worth its fee if the same class of finding cannot quietly return once we have gone.

  1. Pre-commit

    Secret detection runs on the developer machine, so a credential never reaches history. Removing one afterwards is a rotation exercise across every system that trusted it, not a delete.

  2. Pull request

    Static analysis and dependency review run against the diff rather than the whole repository, so the signal is about the change and review stays fast enough that nobody looks for a way around it.

  3. Build

    Image scanning, bill of materials generation and artefact signing. An unsigned or unscanned artefact cannot be promoted to the next environment.

  4. Deploy

    Policy checks against infrastructure definitions and a hard gate on the severities you agreed, with exceptions time limited and attached to a named owner rather than granted indefinitely.

  5. Runtime

    Firewall and rate limit telemetry into the dashboards your engineers already watch, so a blocked attack is visible to the people who can act on it rather than to a console nobody opens.

What you are left holding

  • A threat model per service, maintained as part of the definition of done
  • A pipeline that fails on the findings you agreed should fail it
  • A bill of materials per release, which answers a large part of a customer security questionnaire on its own
  • Firewall and rate limit rules tuned to your traffic and running in blocking mode
  • Minimal, signed container images with no secrets inside them
  • Runbooks written for the engineers who will be on call, owned by them

Tell us what you ship and how often

We will tell you where the gates belong and what they would block in the first month.