A Specialist Practice for Software Security

What We Do

We work on software security at two levels. At the product level, we test applications, APIs, and AI-backed systems, and we review the architecture and code behind them. At the program level, we assess whether an organization actually runs a software-security program, whether its controls operate, and whether it can produce evidence when a customer, a regulator, or a board asks for it.

Then we do the part most firms hand back: building the controls. Pipeline gates, security automation, supply-chain controls, architecture changes, and remediation, implemented in your stack and handed over with documentation.

Engagements are staffed with senior practitioners and scoped to the outcome rather than to a headcount. Reports are written to be acted on, not filed.

How We Work

Engagements are scoped tightly and led by a senior practitioner who stays with the work from kickoff through validation, so context is never lost to a handover. We aim for clarity at every step: what we are looking for, what we found, what to do about it, and how to verify the fix actually holds.

• Senior practitioners on every engagement, start to finish
• Findings written for engineers and executives alike
• Every engagement defines how its results get validated
• Engineering depth to remediate, not just report
• Independent judgment, with no tooling to resell

Who We Work With

Software companies and SaaS providers, AI companies, technology organizations, and product manufacturers with software in the product. Often companies selling into enterprises or government, where software-security expectations arrive through procurement and contracts rather than choice. Sometimes established teams building an application security or product security function for the first time.

The common thread is that the software matters enough that someone is going to ask hard questions about it. If your problem needs depth, we would be glad to talk.

How We Run Our Own Shop

It is fair to ask a security firm what its own posture looks like. Some of these are externally observable from this site. The rest are documented operational commitments covering how we handle systems and engagement data.

• A strict Content Security Policy with no unsafe-inline on scripts or styles, plus HSTS, framing protections, and a Permissions-Policy that disables the APIs this site does not use
• No analytics, no advertising trackers, and no cookies in normal operation. Web fonts are self-hosted, so no third-party font provider receives a request when a page loads
• A published vulnerability disclosure contact at security.txt
• Downloadable artifacts are digitally signed, with the SHA-256 checksum and the signing certificate published so you can verify them yourself
• Multi-factor authentication and least privilege on administrative accounts, with engagement data handling documented in the privacy policy

None of this makes a site secure on its own. It does mean the recommendations we give clients are ones we have already implemented on our own surface.