Cyber Security for Software Houses & Agencies

You are somebody's supply chain

An agency with twenty clients holds twenty sets of production credentials, twenty codebases and twenty deployment pipelines. Compromising you is far more efficient than compromising any one of your clients, and attackers have worked this out.

Your clients are working it out too. Security questionnaires now arrive from customers who never previously asked what a development partner does about security, and "we build secure software" is no longer an adequate answer when the question is about your own environment.

What we consistently find

Secrets in repositories — API keys, database credentials, cloud access keys, committed years ago and still valid because rotating them is somebody's someday task.
Shared client credentials in a password manager everyone can read, or worse, in a document.
Standing production access for developers who needed it once during a launch.
Client environments reachable from one laptop, with no segregation between engagements.
Departed contractors retaining repository or cloud access.
CI/CD pipelines with broad permissions and minimal review on who can modify them.

Two different pieces of work

Testing your own environment

Your infrastructure, your identity provider, your repositories and pipelines, your laptops. This is what your clients are asking about when they send a questionnaire, and it is usually the more urgent of the two.

Testing what you build

Penetration testing of client applications before launch, often commissioned by you on the client's behalf. Worth being clear on commercial terms here: some agencies bundle it, some refer it. Either works, but decide before a client asks, because scrambling to arrange a test two weeks before go-live never ends well.

Secure development, realistically

We are not going to hand you a maturity model. The practical wins are narrow: dependency scanning in CI, secret scanning on commit and in history, a code review step that actually catches authorisation logic, and threat modelling on anything handling money or personal data. Most agencies do one or two of these and assume they cover the rest.

Common questions

Our clients are asking security questions. What do they actually want?

Usually: do you have Cyber Essentials, do you enforce MFA, how do you handle our credentials, what happens when your staff leave, and have you had your own environment tested. Cyber Essentials answers a surprising proportion of it in one document.

Should we test our own environment or our clients' applications first?

Your own. Your clients' applications are their risk; your environment is the one that puts all of them at risk simultaneously. It's also the thing you're being asked about.

Can you test applications we've built, without the client knowing it's you?

We can work as your subcontractor under white-label terms, or directly with the client as an independent provider — which is usually the stronger position, since independence is part of what the report evidences. Either way we don't approach your clients.

We have secrets in old commits. Is that really a problem?

Yes, and rotating the credential matters more than rewriting history. Anything ever committed should be treated as disclosed. Secret scanning across full history usually finds considerably more than people expect.

Cyber Security for Software Houses