BB Store Management
We apply the same Security by Design practice to our own product — threat model before each major feature, OWASP ASVS controls implemented sprint by sprint, secrets scanning in CI from day one. Real engineering, in the open.
Engineering practice
Security by Design
Security baked in, not bolted on. Threat modelling on kickoff, OWASP ASVS L2 controls woven through every sprint, secrets management and dependency scanning in CI. We are engineers who make the thing secure from the first commit — not a firm that tests it after.
Engagement
Security by Design
- Investment
- From £6k
- Timeline
- 2–6 weeks
- Pricing model
- Fixed-price per engagement
- Next availability
- Next slot: 2 weeks
You receive
- Threat model
- Controls Map
- CI hardening
What you get
Security built into the build
Four controls we deliver as engineering practice, not as a one-off assessment.
Threat modelling on kickoff
Before a line of code is written, we map the trust boundaries, data flows, and attack surfaces. STRIDE-based, documented, revisited at each milestone.
OWASP ASVS L2 controls
Authentication, session management, access control, and cryptography implemented to ASVS Level 2 — not as a checklist, as the default way we build.
Secrets management & dependency scanning
No secrets in source — environment-variable discipline enforced from day one. Automated dependency scanning and alerting wired into CI before the first deploy.
Controls Map on handover
Every engagement closes with a Controls Map entry showing which OWASP ASVS and UK GDPR Article 25 controls were implemented and where they live in the codebase.
Who this is for
Use cases
- Teams building products that handle sensitive or personal data
- Products that need OWASP ASVS L2 controls through the build, not bolted on after
- Engineering teams preparing for a client security questionnaire or due-diligence review
- Startups that need a Controls Map artefact for compliance or enterprise sales
- Products subject to UK GDPR Article 25 data-protection-by-design requirements
- Development teams who want threat modelling integrated into every sprint
How we work
Our process
Four phases. Threat model before code. Controls through every sprint. CI hardening from day one.
Threat model
Map trust boundaries, actors, data flows, and the attack surface in writing before implementation begins. Agreed scope, agreed assumptions.
Controls build
OWASP ASVS L2 controls implemented sprint-by-sprint alongside feature work — not deferred to a hardening phase.
CI hardening
Secrets scanning, dependency auditing, and SAST wired into the pipeline. Fails the build if a secret leaks or a critical CVE lands.
Controls Map handover
Delivery closes with a Controls Map entry — control ID, implementation evidence, and the file path. Permanent artefact, not a PDF that goes stale.
What we don't offer
We are engineers, not auditors. We do not offer external testing as a stand-alone service, third-party assessments, or third-party certification programmes.
If you need an external test or a certification assessment, we are happy to work alongside the firm you choose — our Controls Map handover gives them a clean starting point. See our Controls Map for the full position.
Proof of work
We practise what we build
Client work is under NDA. Here's how we apply the same rigour to our own product.
Before you ask
Frequently asked questions
What is Security by Design?
It is a way of building software where security controls are designed and implemented from the start — not retrofitted before a deadline. We use STRIDE threat modelling on kickoff, OWASP ASVS L2 controls through the build, and automated scanning in CI. The goal is a codebase that is secure by default, not one that passes an audit by luck.
Do you offer external testing or stand-alone assessments?
No. We are not a testing or audit firm. If you need a third-party test or a certification assessment, we are happy to work alongside the firm you choose. What we provide is the secure engineering foundation that makes those assessments go smoothly.
What does the Controls Map handover include?
At the close of every Security by Design engagement, we produce a Controls Map entry — a record of which OWASP ASVS and UK GDPR Article 25 controls were implemented, where in the codebase they live, and any residual risks noted. It is a permanent, versioned artefact, not a one-time report. See our public Controls Map at /legal/controls-map.
Can you help us prepare for a client security questionnaire or supplier due-diligence review?
Yes. The Controls Map handover is designed to answer exactly those questions — control by control, with evidence. If your customer or assessor uses a specific framework, tell us at scoping and we will map our delivery to it.
How do you handle secrets and credentials?
No secrets in source — ever. We use environment-variable discipline enforced from the first commit, automated secret-scanning in CI (fails the build on detection), and a documented rotation procedure. We also audit the dependency graph for known vulnerabilities on every CI run.
Ready to build security in?
Tell us what you're building — we'll reply within 24 hours on working days with a threat model scope, a fixed price, and a realistic start date.