Security Engineering
Security that arrives as a report at the end of a project produces a backlog nobody funds. We would rather work inside your delivery process, where a design decision can still be changed cheaply.
Threat modelling beats checklists
A checklist tells you whether you did the standard things. A threat model tells you what someone would actually try against your system, which is a different and more useful question. The two are not interchangeable, though compliance frameworks often encourage treating them as such.
We run threat modelling as a working session with the engineers who built the thing. It usually takes half a day, surfaces issues no scanner would find, and leaves the team better at spotting the next one without us.
Where we help
Architecture review
Trust boundaries, authentication and authorisation design, data flows and blast radius — assessed while changing them is still inexpensive.
Secure delivery
Dependency scanning, secret detection, static analysis and infrastructure policy checks in the pipeline, tuned so the findings are worth reading.
Identity and access
Authentication flows, session handling, service-to-service credentials and permission models that stay comprehensible as the system grows.
Cloud posture
Network boundaries, key management, logging and least-privilege roles, reviewed against how your environment is actually configured rather than how it was documented.
Testing
Targeted penetration testing against the areas your threat model flagged, with findings written to be actionable by the engineers who will fix them.
Incident readiness
Detection worth alerting on, a response plan people have rehearsed, and logging that will answer the questions you will have at two in the morning.
How an engagement runs
Model the threat, name the attacker
Who would come for this, what they would want, and which paths are open to them. A threat model with no named adversary produces a checklist, and checklists find generic problems.
Look at the paths that matter
Authentication, authorisation boundaries, data at rest and the third parties you have quietly trusted. Depth on the real paths beats breadth across everything.
Put findings in the normal backlog
With owners, severity and dates, alongside feature work. A separate security backlog is a backlog that does not get done.
Build the controls into delivery
Secrets management, dependency policy and least-privilege access enforced by the pipeline rather than by a policy document nobody reads.
Rehearse the incident
A tabletop at minimum, annually. The first time you find out your response plan does not work should not be during an actual breach.
What you are left with
Living threat model
Kept next to the architecture and updated when the architecture changes, not filed once.
Triaged findings
In your tracker, with owners and dates, and a severity scale your team agreed to.
Pipeline controls
Secrets, dependencies and permissions enforced automatically at deploy time.
Response plan
Written, with contacts, and rehearsed at least once so you know where it breaks.
Compliance, honestly
Frameworks like ISO 27001 and SOC 2 are useful scaffolding and poor substitutes for judgement. They describe controls a reasonable organisation should have; they cannot tell you which risks are specific to your architecture.
We help teams meet these obligations without pretending the certificate is the goal. In practice most of the evidence should fall out of engineering practices you would want anyway — access review, change control, logging, tested backups. Where a control is genuine overhead with no security benefit for you, we will say so rather than perform enthusiasm for it.
Threat model maintained alongside the architecture, not filed once
Security findings triaged into the normal backlog with owners
Evidence generated by practice rather than assembled before an audit
Response plans rehearsed at least annually
When not to hire us
Maplecode holds no security certifications. If your procurement requires an ISO 27001 or SOC 2 certificate from your supplier, we cannot satisfy that, and no amount of good engineering changes it.
We can help you build toward your own certification, and we will not pretend a penetration test report is the same thing as a secure system. If someone has sold you that, it is worth a second opinion.
Common questions
Yes, though it is worth asking what the customer actually needs. If it is assurance, a test against a system with known unaddressed issues will produce an uncomfortable report. We often suggest a short review and remediation pass first, so the formal test reflects your real posture rather than a backlog.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.