Executive summary

This article documents an ongoing SSDLC integration effort, focusing on practical trade-offs between engineering, management, and business constraints. SSDLC here is treated not only as a technical practice, but as an organizational and business decision.

Over the past week, I integrated a secure software development lifecycle (SSDLC) into our development process. The framework consists of five stages, and this week I completed Stage 1 (risk assessment) and Stage 2 (threat modeling), and began the security design review.

This publication covers the details of integrating SSDLC, focusing on the first two stages.

Business context

SSDLC competes with delivery speed and product priorities. The decision to adopt SSDLC is fundamentally a trade-off between risk tolerance and delivery velocity.

Back in 2023, I highlighted the importance of integrating SSDLC into the development process. Since then, demand has grown even further. Over the past eight years, implementing security requirements in software has evolved from a "nice-to-have" into a "must-have" capability.

Industry reports shown only banks, PaaS providers, and large enterprises can consistently afford full SSDLC implementation. Mid-range businesses can adopt it partially, while smaller companies often recognize the need but lack the budget.

The cost. Salesforce's case study shows 3 months of pure team training, up to 30% time-to-market increase, ROI return back after 12 months. For a small team like ours, we expect up to 100% increase in time-to-market in the first 2 months, up to 20% increase in time-to-market afterwards.

In our case my origin estimates still looks within expectations, but threat modelling stage and design review stage shown significant increase in invested man-hours. Both metrics still fits in estimates from Salesforce case study adopted to a project of our size and domain.

Talents on worldwide market. Ballpark estimate.

Level Capability % of engineers
Aware Know what STRIDE / SSDLC is ~20–30%
Intermediate Can participate in threat modeling ~10–15%
Advanced Can independently model threats ~5–10%
Expert Can embed SSDLC into org/process ~2–5%
Architect-level Can scale SSDLC across org ~1–3%

Secure software development overview

The secure software development lifecycle (SSDLC) is the industry's response to the growing number of cyberattacks. While it does not guarantee protection against vulnerabilities or exploitation by malicious actors, it significantly reduces risk and improves cost predictability.

The cost of fixing a vulnerability increases exponentially over time: approximately $100 at the design stage, $1,000 during development, and $10,000 in production. SSDLC shifts issue detection to earlier stages ("shift-left"), helping businesses avoid costly incidents.

SSDLC typically consists of five stages:

  1. Risk assessment
  2. Threat modeling
  3. Security design review
  4. Static code analysis and security scanning
  5. Penetration testing
In essence, SSDLC extends the standard software development process by embedding security practices into each stage.

Risks assessment

The primary goal of risk assessment was not documentation, but decision-making:

  • what to fix now
  • what to fix later
  • what to postpone

The intent behind this stage is go through software requirements and identify potential security risks -- what could goes wrong.

The result of this stage is a document which summarise discovered threats in format:

  • Requirement
  • Asset
  • Threat
  • Attack vector
  • Impact / Likelihood / Risk
  • Controls

Starting from basic Threat → Risk → Mitigation it evolves further to something like this:

The table above should became the central artifact used across engineering and management discussions.

  • Owner → responsibility
  • Priority → planning
  • Tracking → control of execution

A simplified "Threat → Risk → Mitigation" model looks minimal necessary and sufficient, but it would not pass mature enterprise level security audit:

  • there is no link to real hacker attacks
  • there is not clear statement of the cause
  • there is no way to validate it
This led to extend this basic table to the table shown above.

Threat modeling

Threat modeling is the next stage in SSDLC, based on gathered requirements and evaluated risks. If risk assessment answers the question “what can go wrong”, then threat modeling answers “how it could realistically happen in the system”.

The primary objective of this stage is not documentation, but validation and execution: to ensure that identified risks are technically plausible, to model realistic attack scenarios, and to define concrete security controls at the architectural level.

Objectives

  • Validate that risks are technically plausible
  • Identify realistic attack scenarios
  • Define architecture-level security controls
  • Ensure traceability from risks to mitigations

Methodology and standards

The approach combines elements of PASTA (process), STRIDE (threat enumeration), and NIST SSDF (completeness and audit readiness).

In practice, a simplified hybrid model was used to balance engineering usability and alignment with industry standards.

Assets

The first step is identifying critical assets and their security properties. Threat modeling is always tied to assets, not abstract concepts.

Asset Category CIA Priority Related Risks
Vote data (ballot) Vote secrecy & integrity C + I R2, R3, R8
Voter ↔ Vote link Anonymity C R2–R4
Identity (card + session) Authentication I + A R5, R17
Client application (Aurora) Endpoint I + A R12, R26
Backend services + DB System core All Multiple
Logs Audit / privacy C + I R13, R25

Trust boundaries

The system is decomposed into trust zones. Each boundary represents a change in trust assumptions and therefore a critical control point.

Boundary Description Inside Outside Critical Transition
Client ↔ Network Untrusted environment Aurora client External network Request submission
Network ↔ Backend API perimeter Application services External traffic Secure communication channel
Identity ↔ Voting Critical separation boundary Authentication domain Voting domain Anonymous authorization

Data Flow Diagram (DFD)

A Level 1 Data Flow Diagram (DFD) was constructed to formalize system interactions between external users, client components, backend services, and storage layers.

The DFD serves as a shared model between engineers and security reviewers and is used as a basis for systematic threat enumeration.

STRIDE analysis

Each component was evaluated using STRIDE to ensure coverage across all major threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation.

Component S T R I D E
Client ✓✓✓✓✓—
Auth Service ✓✓—✓✓✓
Core Service —✓✓✓✓✓
Logging —✓✓✓——

Threat scenarios

The core artifact of this stage is a set of explicit threat scenarios, structured as:

Threat → Vulnerability → Scenario → Control

Scenario Threat Vulnerability Control Residual Risk
Deanonymization Correlation attack Metadata linkage potential Unlinkability, data minimization Medium
Data manipulation Integrity violation Insufficient integrity guarantees Cryptographic verification, append-only storage Low–Medium
Impersonation Unauthorized access Weak authentication factors Multi-factor authentication, session binding Medium
Undetectable attack Audit evasion Limited observability Immutable audit trail, monitoring High

Attack scenario illustration

For critical threats, multi-step attack scenarios are considered at a conceptual level. Controls are designed to break potential attack chains at different stages.

Example: correlation-based deanonymization is mitigated through a combination of access control, data minimization, and cryptographic separation mechanisms.

Residual risks and trade-offs

Not all risks can be eliminated. Threat modeling explicitly identifies residual risks and documents acceptance decisions.

Residual Risk Level Decision Owner
Undetectable insider activity High Accepted (trade-off with privacy) CIO
Side-channel correlation risks Medium Accepted Security Architect

Related publications:

Why you need to setup secure software development lifecycle (SSDLC)
Case study: establish an information security of a government organization
Broad vs Narrow specialisation