Security software engineering
Put the security decision where the design still moves.
Security software engineering connects architecture, delivery pipeline, product requirements and release evidence. Examine those relationships in the product you are actually shipping, so that controls sit beside the code and the decisions they protect.
Security holds at the boundary the product actually has
- Untrusted input
- Content, callers and dependencies the product does not control.
- Enforcement point
- The place where authority is checked before an effect occurs.
- Privileged effect
- The write, transfer, grant or device action that carries consequence.
- Release evidence
- What a specific build can demonstrate about all three.
Discipline model
A weakness becomes consequential through an enforcement gap
The relationships that define the discipline
- Architecture
- Trust boundaries decide what an attacker would have to cross.
- Delivery
- The pipeline decides which checks a change cannot avoid.
- Product surface
- Interfaces, devices and firmware carry the reachable effects.
- Release
- Evidence decides what this build is allowed to claim.
A security weakness matters because of the effect it can reach. Follow the path from an untrusted caller, document or dependency to the operation that changes state, and ask where authority is checked along the way. That places architecture, delivery controls, interface enforcement, embedded surfaces and release evidence in one view, instead of treating a scanner finding as the whole picture.
Illustrative situation
A gateway check protects an interface that is reachable without it
A constructed situation and the question it raises
Illustrative scenario
- The design
An internal service gains an external gateway that performs the tenancy check.
- The assumption
Every caller is assumed to arrive through the gateway.
- The question
What happens when a caller reaches the service directly?
Consider a service that was built for internal callers and later exposed to partners through a gateway. The gateway checks tenancy, so the interface appears protected. The useful question is whether the underlying service is reachable without the gateway, and what a caller could read or change if it were. The answer decides whether the control belongs at the edge, at the point of effect, or at both.
Working approach
Separate the design intent from the enforced behaviour
From stated intent to inspectable evidence
- State the property
Write the security requirement so a test could refute it.
- Locate enforcement
Find where the check actually runs, not where it is documented.
- Produce evidence
Record what the current build demonstrates and what it does not.
Security intent is usually easier to find than security enforcement. The work restates each obligation as a property with an actor, a precondition and an observable result, then looks for the place that property is enforced in the running system. Where intent and enforcement diverge, the difference is the finding. That approach keeps a documented control from standing in for an operating one.
Working artefact
Connect each finding to a control and a release decision
What a useful security finding carries with it
Illustrative working format
- Reachability
- The conditions under which the weakness can actually be exercised.
- Consequence
- The effect on data, customers or the device fleet.
- Disposition
- The fix, the accepted risk or the named exception with its owner.
A finding without reachability, consequence and disposition becomes another row in a backlog. The artefacts this discipline produces are meant to survive that: a threat model whose paths carry reachability conditions, a remediation plan grouped by underlying cause, and a release evidence pack that says which properties the current build actually demonstrates. Each connects to a decision someone is accountable for.
Scope and next decision
Keep the conclusion inside the examined configuration
What this work does and does not establish
- Included
- Design, code, configuration and evidence within the agreed boundary.
- Excluded
- Penetration testing, certification and guarantees of resistance.
- Retained
- Your owner keeps release, remediation and risk decisions.
Review work reports on what was examined. It does not establish that a system resists attack, and it does not certify a product against a standard. Intrusive testing, laboratory hardware work and formal analysis need separately qualified specialists and their own scope. Start with one product, one change and the evidence already available, and the useful boundary usually becomes clear quickly.
Explore the discipline
Specialist areas within this capability
Choose a question to explore its methods, boundaries and indicative outputs.
- Secure software architecture and threat modelling
- Secure development lifecycle and DevSecOps
- Product security requirements and security-by-design
- Application, API and integration security engineering
- Secure code review and vulnerability remediation
- Software supply-chain security and dependency control
- Embedded and IoT security engineering
- Firmware security, secure boot and signed updates
- Security protocol design, review and implementation
- Identity, authentication, authorisation and secure-session engineering
- Security testing and release assurance