Posts

Why SSDLC is helping shipping faster and more secure code

21/07/2026/in Educational

Software Delivered the Same Way Every Time

Before security enters the picture, SDLC exists to solve a simpler problem: making software delivery repeatable. A team that builds features ad hoc, without a defined sequence of requirements, design, coding, testing, and release, ends up with wildly inconsistent outcomes — some releases solid, others full of regressions, and no reliable way to tell in advance which kind you’re getting. A defined lifecycle turns software development from a craft that depends on who happens to be doing it into a process with predictable checkpoints: requirements are captured and reviewed before design starts, design is reviewed before coding starts, and testing has defined entry and exit criteria rather than being whatever time is left before the deadline. That structure is what makes quality reproducible — not because any single stage guarantees a good outcome, but because catching a problem at the design review is far cheaper than catching it after three sprints of code have been built on top of a bad assumption.

Bringing Security Into That Same Structure

Secure SDLC takes that same reasoning and applies it to security specifically: if reproducible quality comes from catching problems early, in the exact stage where they’re cheapest to fix, then reproducible security should come from the same discipline, rather than from a scan run the week before release.

So, the strongest argument for SSDLC is cost (but definitely not the only one !) , which can be of multiple types — the well-established pattern across the industry is that a vulnerability caught during design or code review costs a fraction of what it costs to fix once it’s in production, and a fraction of that again once it’s been exploited and triggers an incident response.

That’s why Secure Software Development Lifecycle (SSDLC) shouldn’t be a separate track that runs alongside development — it is development, done with the assumption that someone will eventually try to break what you build. Teams that treat security as a gate before release end up with the worst of both worlds: slower delivery and no real reduction in vulnerabilities, because the flaws were baked in during design and coding, long before any scanner or pen tester got a look at the code. SSDLC works by moving that attention earlier, into requirements, architecture, and the daily habits of developers, rather than bolting it on at the end.

The practical starting point is threat modeling at the design stage, before a line of code is written. This doesn’t need to be an elaborate exercise — even a lightweight session asking what could go wrong with this feature and who would want to exploit it catches a surprising share of the issues that would otherwise surface as CVEs a year later.

From there, secure coding standards and mandatory code review with a security focus matter more than any single tool, because most real-world vulnerabilities come from ordinary logic errors: missing authorization checks, trusting client-side input, mishandling secrets.

Static analysis and dependency scanning are useful, but they catch a narrower slice of problems than people expect, and treating them as the whole strategy is a common and costly mistake.

Where I’ve seen SSDLC actually stick in an organization is when it’s expressed through Security User Stories rather than a separate compliance checklist.

A story as simple as “As an attacker, I should not be able to access another user’s data by changing the ID in the URL” gives developers something concrete to build and test against, and it fits naturally into existing sprint planning instead of competing with it. Thinks that this by default and nobody would ever do something like that in their code? You are wrong. Many developers are working under pressure to deliver quickly, don’t use AI and are sometimes unexperienced. They cut corners. Always…

This also matters for CRA and NIS2 compliance, both of which increasingly expect documented evidence that security was considered throughout the lifecycle, not just verified at the end. Framing security work as user stories creates that evidence trail almost as a byproduct of normal delivery, which is a much easier sell to engineering teams than a parallel security process they resent.

One honest caveat: SSDLC adds real overhead to the early stages of a project, and for a small team under deadline pressure that tradeoff can feel expensive in the moment.

The payoff shows up later, in fewer emergency patches and audit findings — but I’d flag that as a claim based on typical outcomes I’ve seen in consulting engagements, not something I can quantify precisely for every organization.

The post Why SSDLC is helping shipping faster and more secure code first appeared on Sorin Mustaca – Security & Technology.

Security User Stories How-To – for product managers and developers

11/07/2026/in Educational

I wrote some time ago about “How to create security user stories” and I received in the meanwhile a lot of good feedback and questions about it.

For these reasons, I decided that it is time to write again on the topic, this time with focus on two importat groups in any software developer team: Product Managers and software developers.

What a Security User Story actually is and why it needs modification for security

A regular user story captures what a user wants to do and why, following the format:

As a [role], I want [goal], so that [benefit].

A security user story does the same thing, but the “role” is often a threat actor, a security control, or a compliance requirement — and the “benefit” is about preventing harm rather than enabling convenience. Most teams write functional stories and then bolt security on at the end as a checklist. That approach fails because security requirements that arrive late in a sprint get trimmed, deferred, or implemented incorrectly because nobody thought about them during design.

The correct mental model is this: security stories live in the same backlog as functional stories, they get estimated, they get accepted or rejected based on clear criteria, and they block a release when they aren’t done. They are not a separate audit artifact. They are not a penetration test report reworded as tickets. They are engineering requirements written with enough precision that a developer can implement them and a tester can verify them without reading anyone’s mind.

For security work, the format above breaks down quickly because it was designed for positive outcomes — a user wanting access to something. Security stories often describe preventing something, enforcing a constraint, or ensuring a system behaves correctly under adversarial conditions.

A more useful format for security stories adds a threat context and a verification condition:

As a [role or attacker], I want [action or capability] so that [outcome] — therefore the system must [control] which can be verified by [test condition].

The verification condition is what separates a useful security story from a wish. If you cannot write a concrete test that passes or fails, the story is not ready to be worked on.

What Product Managers are responsible for

The product manager’s job is not to write the technical implementation details. It is to make security requirements visible, prioritized, and connected to real risk. PMs tend to treat security as either non-negotiable compliance overhead or as something the security team handles separately. Both attitudes produce bad outcomes.

In the “Ideal world”

The PM writes the threat context. This means thinking like an attacker long enough to articulate what someone with bad intentions could do with the feature being built. A PM building a file upload feature should be asking: who uploads files, what happens to those files after upload, and what is the worst realistic thing that happens if an attacker controls the file content. That thinking produces a security story. The absence of that thinking produces a feature with a file upload vulnerability discovered six months later.

PMs also own prioritization. A security story that prevents account takeover ranks higher than one that adds a password complexity rule nobody will read. That judgment requires understanding the actual risk exposure of the product, which means PMs need enough security literacy to have the conversation with their security team rather than outsourcing the entire decision.

But this is just “ideal” – which means it almost never happens. Or, at least, I have never seen this done in 25 years of product management.

In the “real world”

The PM doesn’t care about security. For the PM, it is by default assumed that the technical team will implement the feature secure by design, by default and by deployment.

This “not my concern” attitude creates a lot of friction in the development teams.

So, then, who creates the security user story?

What Developers Are Responsible For

The developer’s job is to take a security story and implement the control correctly, then write the acceptance criteria into an automated test. Developers often receive vague security requirements — “ensure input is validated” or “use secure coding practices” — and have no way to know whether their implementation is correct because the requirement has no measurable outcome.

When a developer receives a well-formed security story, the implementation work splits into two parts. First, the technical control: how does the code actually enforce what the story requires. Second, the negative test: does the code fail correctly when the control is bypassed or when an attacker sends unexpected input?

Developers should be writing both happy-path and adversarial tests for security stories. If the story says “the system must reject file uploads where the MIME type does not match the file extension,” the developer writes a test that sends a PHP file renamed as a JPEG and confirms the server returns a 40x code. That test becomes a regression guard. It will catch the next person who refactors the upload handler and accidentally removes the validation.

Example developer-implemented security story with acceptance criteria:

As a developer implementing the password reset flow, I need to ensure the reset token cannot be guessed or reused so that an attacker who intercepts or brute-forces the URL cannot take over an account.

Acceptance criteria written by the developer before coding begins: the reset token must be generated using a cryptographically secure random function producing at least 128 bits of entropy. The token must be stored as a bcrypt hash, not plaintext. The token must expire 15 minutes after generation. The token must be invalidated immediately after it is used once. A request with a token that was already used must return a 400 with no indication of whether the token was valid. These criteria become the test suite, not the documentation.

Hard, isn’t it? A lot of knowledge is required about crypto, OAuth2, etc.

Can developers do this?

How to implement this in practice

The first step is adding a threat modeling checkpoint to the definition of done (DoD) or at least in the checklists for development phases. Before a story moves into a sprint, the team asks: does this story touch authentication, authorization, data storage, external input, or external communication? If yes, a corresponding security story must exist in the backlog before the functional story is pulled in.

The second step is building a library of security story templates for common patterns. You don’t need to invent this library, there are plenty of resources available online.

Start from the common frameworks like OWASP, STRIDE, NIST, etc:

SQL injection prevention,
CSRF protection,
secure file handling,
secrets management, and rate limiting
how are Confidentiality, Integrity, Availability (CIA) affected at various stages, with different types of data

all appear repeatedly across features. A template gives the team a starting point rather than expecting developers and PMs to derive the requirement from scratch every time.

The third step is treating failed security acceptance criteria the same as failed functional tests. If a security story is not done, the feature is not done. This requires management buy-in, but it is the only way to prevent the pattern where security stories accumulate in the backlog indefinitely while features ship without their corresponding controls.

The fourth step is reviewing security stories in sprint retrospectives. Not the controls themselves, but the process: were the stories specific enough to implement, did the acceptance criteria hold up during code review, did any security debt get created because the story was underspecified. That feedback loop is what makes the team better at writing them over time.

The Three Most Common Failures

The first failure is writing security stories as restrictions without context. “The system must not allow SQL injection” tells a developer nothing actionable. It does not say where the injection risk exists, which inputs are affected, or how to verify the control is working. The correct version identifies the specific input vector, the parameterization or ORM requirement, and the test that confirms raw SQL cannot be injected through that input.

The second failure is writing security stories only after a penetration test. Pen test findings are useful, but treating them as the primary source of security stories means the team is always reacting to vulnerabilities in shipped code rather than preventing them during design. Security stories belong at feature inception, not at audit time. Best is to update the templates after each set of findings, so that you don’t repeat the issues next time.

The third failure is accepting security stories with vague verification conditions. “The login must be secure” cannot be tested. “The login endpoint must lock an account for 30 minutes after 5 consecutive failed attempts, respond with a 429 on the sixth attempt, and not disclose whether the lockout is due to the account not existing or the password being wrong” can be tested. The difference between these two is the difference between a team that thinks about security and a team that actually builds it.

Instead of conclusions

So, who is expected to create the security user stories?

Usually, PMs don’t know how and don’t think it is their problem anyway.

Most developers have not beein trained into thinking offensive security. Actually, vast majority never even had a formal training in writing secure code for their platform.

I think that the answer depends on the organization size, type and focus.

Small organizations (< 50 developers) : everybody should work together, use as much as possible templates from tools and online resources.

Medium organizations (51-200 developers) : you should have dedicated people with formal training in security. It can be that they are occupying the role of PM or developer or architect. Start from the same things as small sized organizations and adapt everything for your needs, if you can.

Large organizations (200+ developers) : you should have dedicated security architect, security developers and other roles trained in secure development. You should have your own set of templates and tools to be used. Your SDLC must include mandatory security user stories.

The post Security User Stories How-To – for product managers and developers first appeared on Sorin Mustaca – Security & Technology.

SOC 2 Type 2 mapping to Secure SDLC Requirements

30/04/2026/in Educational

We started to talk about the SOC2 Type 2 certification and I feel that we neglected it a bit.

I wrote a bit about SDLC, Secure SDLC in particular, but now it is time to bring them together.

SOC 2 Type 2 and Secure SDLC — the big picture

SOC 2 Type 2 evaluates whether controls are operating effectively over time (typically 6–12 months). It is not a point-in-time snapshot.

Your SDLC is not an isolated engineering practice — it feeds directly into several Trust Services Criteria (TSC).

All nine Common Criteria map to the SDLC in some way, but they do so at different layers.

CC1 (Control Environment) is the foundation. It is not about code or process — it is about organizational accountability. The auditor checks that your Secure SDLC has a named owner, that the policy carries formal authority, and that security has a defined role in the development organization. Without this, every other control lacks a governance backbone.

CC2 (Communication) requires that developers know the rules. A Secure SDLC policy that exists but was never distributed or acknowledged does not satisfy this criterion. The auditor looks for training records, policy sign-offs, or equivalent evidence that the people making security decisions in each SDLC phase were aware of their obligations.

CC3 (Risk Assessment) maps directly to the Idea and PoC phases. The criterion requires that risks are identified and analyzed before work begins. A threat model, a risk register entry, or a documented security review of the proposed design all serve as evidence. The auditor wants to see that risk was considered as an input to scope decisions, not evaluated after the fact.

CC4 (Monitoring Activities) requires ongoing evaluation of whether controls are working. In SDLC terms this means SAST, DAST, and SCA scans must run regularly, their results must be reviewed, and findings must be tracked to resolution. Running a scan whose results are never acted on does not satisfy CC4.

CC5 (Control Activities) covers the specific rules that govern how code is written and reviewed. Secure coding standards, mandatory peer review, branch protection, and secrets scanning policies all live here. CC5 is about the guardrails built into the development process itself, not just the approval chain around it.

CC6 (Logical Access) runs across the widest range of SDLC phases. It covers who has access to source code, build pipelines, deployment tools, and production environments — and whether that access is appropriate at each phase. PoC access that was never revoked and production credentials embedded in a repository are both CC6 findings.

CC7 (System Operations) requires that running systems can detect and respond to threats. Its SDLC relevance is that logging, alerting, and incident response readiness must be built into the product before it reaches production. If these are treated as post-launch concerns, CC7 is a gap.

CC8 (Change Management) is the criterion most directly owned by the SDLC. Every code change from PoC through EOL must be authorized, reviewed, and traceable. This criterion generates the highest sample volume in a Type 2 audit — typically 20 to 25 change records — and every sampled item needs a complete evidence chain.

CC9 (Risk Mitigation) addresses third-party and vendor risk. In a software development context this means evaluating open-source libraries, SDKs, and external dependencies before they are adopted. Running a dependency scan satisfies part of this, but CC9 specifically requires that a conscious risk decision was documented — not just that a tool ran.

The practical takeaway is that CC1, CC2, and CC9 are the ones most commonly missing from customers who think their Secure SDLC is well covered.

They focus on CC8 (change management) and CC6 (access) but leave governance, communication, and vendor risk undocumented.

Summary mapping of SOC2 controls to SDLC

CC	Control Name	Idea	PoC	MVP	Release	EOL	SDLC Intersection / Evidence
CC1	Control environment	✓	—	—	—	—	SDLC policy with named owner. Security team has formal authority to block releases.
CC2	Communication	✓	✓	✓	—	—	Secure SDLC policy published and acknowledged. Developer training completion records.
CC3	Risk assessment	✓	✓	—	—	—	Threat model at Idea phase. Risk register updated before PoC scope is confirmed.
CC4	Monitoring activities	—	—	✓	✓	—	SAST/DAST results reviewed. Recurring vuln scans in prod. Findings tracked to closure.
CC5	Control activities	✓	—	✓	✓	—	Secure coding standards doc. Code review policy enforced. Branch protection rules active.
CC6	Logical access	—	✓	✓	✓	✓	Repo and pipeline access logs. Secrets management reviewed. Prod access revoked at EOL.
CC7	System operations	—	—	✓	✓	✓	Logging enabled pre-release. Alerting configured in prod. Incident runbook referenced.
CC8	Change management	—	✓	✓	✓	✓	PR records with approvals. Pipeline gates enforced. EOL change ticket required.
CC9	Risk mitigation	✓	✓	—	—	—	Third-party libraries assessed. OSS license and security risk reviewed before adoption.

Practical Checklist — SDLC Evidence by Common Criteria

CC1 — Control environment

SDLC policy with version, date, and named owner. Org chart showing security’s authority. Evidence security can block a release.

CC2 — Communication

Policy acknowledgment log with names and dates. Annual security training completion records. Re-communication evidence if policy changed during the audit period.

CC3 — Risk assessment

Threat model dated before PoC began. Risk register with severity ratings and owners. Security requirements traceable to backlog items.

CC4 — Monitoring activities

SAST and SCA scan reports on a recurring cadence, not one-off. Vulnerability remediation log showing finding, severity, owner, SLA target, and closure date.

CC5 — Control activities

Secure coding standards document. Branch protection configuration blocking direct pushes to main. Secrets scanning active in the repository.

CC6 — Logical access

User access list per environment with roles. Annual access review log. MFA enforcement evidence. Secrets stored in a secrets manager, not in code. Access revocation records for leavers and decommissioned systems.

CC7 — System operations

Logging configuration in place before first production release. Alerting thresholds and escalation paths documented. At least one security alert triaged and recorded during the audit period.

CC8 — Change management

PR records with reviewer names and approval timestamps for every sampled change. Pipeline logs showing tests passed before deployment. Rollback procedure documented. Change ticket for every production deployment including EOL.

CC9 — Risk mitigation

Dependency evaluation process documented. SCA reports showing library risk at adoption and on a recurring basis. Risk acceptance record for each significant new dependency introduced during the audit period.

Secure SDLC and SOC 2 Type 2 — Summary

SOC 2 Type 2 evaluates whether security controls operated consistently over an audit period, typically 6 to 12 months. A Secure SDLC is not a separate compliance workstream. It is the operational mechanism through which most of the Common Criteria are satisfied.

All nine Common Criteria (CC1–CC9) have at least one touchpoint in the SDLC. No phase is audit-free.

Idea is the most governance-heavy phase. CC1, CC2, CC3, CC5, and CC9 all apply here. Before a single line of code is written, the auditor expects a threat model, a risk register entry, a policy that developers have acknowledged, and evidence that third-party dependencies were evaluated. Skipping security at this phase creates gaps that are difficult to close retroactively.

PoC is where CC6 findings most often hide. Auditors check whether PoC environments were isolated from production data and whether access granted during PoC was later revoked. CC8 also applies — even exploratory work needs a change record.

MVP is the most evidence-dense phase and where auditors spend the most time. CC4, CC5, CC7, and CC8 all apply. The auditor will sample pull request records, SAST and SCA scan reports, vulnerability remediation logs, and logging configuration. Controls must have operated on every change, not just most of them.

Release is primarily about authorized change (CC8) and least-privilege access to production (CC6). Pipeline logs are strong evidence because they show controls were enforced automatically. A documented rollback procedure satisfies CC7.

EOL is the most commonly under-documented phase. CC6 requires proof that access was revoked. CC8 requires a change ticket for the decommission. CC7 applies if the system handled live data up to shutdown. Data disposal records satisfy C1.2 if confidentiality is in scope.

The controls most frequently missing in practice are CC1 (no named SDLC policy owner), CC2 (policy exists but was never formally acknowledged by developers), CC7 (logging treated as a post-launch concern rather than a release requirement), and CC9 (dependency risk decisions not documented, even when scans were run).

The key principle for SOC 2 Type 2 is consistency. A control that worked 90% of the time is still a finding. Every sampled change needs a complete evidence chain from its originating phase through to deployment or decommission.

The post SOC 2 Type 2 mapping to Secure SDLC Requirements first appeared on Sorin Mustaca’s blog.

How-To create Security User Stories

20/10/2024/in Educational

In the previous article, we explored how Scrum enables teams to add security to the backlog and prioritize it based on risk.

Incorporating security into the SDLC ensures that security is not an afterthought but an integral part of the development process.

Security User Stories are specific, actionable items that articulate the security needs of the software in the same way functional requirements are handled.

Writing Security User Stories complements this process by providing clear, actionable security requirements that can be integrated into each sprint.

By treating security stories with the same importance as functional stories, developers can ensure that the software they build is not only feature-complete but also secure.

What are Security User Stories?

Security User Stories are descriptions of security requirements written from the perspective of the user or the system. They focus on specific security needs, ensuring that the software not only meets functional requirements but also protects against potential vulnerabilities. Just like traditional user stories that describe a feature or function, security stories express how the system should behave securely.

A typical Security User Story follows the same format as a regular user story:

As a [role], I want [goal], so that [benefit].

For example, a Security User Story for web development might look like this:

“As a user, I want my session to expire after 15 minutes of inactivity, so that my account is protected from unauthorized access.”

Why are Security User Stories Needed?

Security is often treated as an afterthought, addressed late in the development process or after an incident occurs. This reactive approach leads to vulnerabilities, increased technical debt, and costly security fixes post-release. Security User Stories shift this paradigm by making security an integral part of the development process from the outset. They are necessary for several reasons:

Proactive Security Integration: By incorporating security needs into the backlog from the start, you ensure that security considerations are addressed in each sprint, reducing the risk of vulnerabilities later on.
Clear Requirements for Developers: Security User Stories provide clear, actionable security requirements, helping developers understand exactly what is expected to make the software secure.
Accountability: Writing security stories holds the development team accountable for implementing security features and allows for better tracking of security tasks within the development cycle.
Risk Mitigation: When security is considered early in the SDLC, potential security issues are identified and addressed before they become significant risks. This aligns with the concept of “Shift Left” security, where security is integrated into earlier stages of the development process.

How to Use Security User Stories

Security User Stories should be written as part of the Product Backlog and prioritized based on the level of risk or impact. Here’s how to use them effectively:

Collaboration with Security Experts: Work with security professionals to identify potential threats and risks specific to the application or platform. They can help create and refine security user stories based on threat modeling and vulnerability assessments.
Define Acceptance Criteria: Each Security User Story should have clear, testable acceptance criteria. These criteria define when the story is considered complete and what tests should be performed to verify the security requirement has been met.
Prioritize Based on Risk: Security User Stories should be prioritized just like functional features, based on their importance. Stories that address high-risk vulnerabilities, such as authentication or encryption, should be prioritized early in the development cycle.
Regular Review and Updates: Security is an evolving field. As new threats emerge, Security User Stories should be reviewed and updated to address the latest vulnerabilities. Regular threat assessments help ensure the backlog remains current.

Examples of Security User Stories Across Different Platforms

1. Web Application Development

Web applications face numerous security threats, from SQL injection to Cross-Site Scripting (XSS). Below are examples of Security User Stories that address common web application security issues:

“As a user, I want my password to be stored securely using a strong hashing algorithm like bcrypt, so that my account is protected from unauthorized access.”
“As a system, I want to validate all user inputs server-side to prevent injection attacks.”
“As a system, I must use HTTPS for all data transmitted between the client and the server, to ensure data confidentiality.”
“As a user, I want to be logged out after 15 minutes of inactivity, so that my session cannot be hijacked.”

2. Windows Software Development

Windows software may face risks such as privilege escalation or malicious code execution. Security User Stories for Windows development could include:

“As a user, I want my application to run with the minimum necessary privileges, so that the system is protected from privilege escalation attacks.”
“As a system administrator, I want all logs to be stored securely and be tamper-proof, so that I can audit user activities reliably.”
“As a developer, I want the application to verify all digital signatures before executing code, to ensure the code has not been tampered with.”
“As a system, I want to enforce Data Execution Prevention (DEP) to prevent malicious code from executing in the memory.”

3. Android App Development

Mobile applications, particularly Android apps, face unique security challenges, such as improper storage of sensitive information and unauthorized access to device features. Examples of Android-related Security User Stories include:

“As a user, I want my sensitive data (e.g., passwords, payment information) to be encrypted using the Android Keystore system, so that my data is safe even if the device is compromised.”
“As a developer, I want the app to request only the necessary permissions, so that the user’s privacy is respected.”
“As a user, I want to be required to authenticate using biometrics before making sensitive changes, such as resetting my password, to ensure the security of my account.”
“As a system, I want to securely store session tokens and prevent them from being accessible via insecure storage mechanisms (e.g., SharedPreferences).”

4. iOS App Development

iOS apps must adhere to strict privacy and security guidelines, and improper handling of user data can lead to severe breaches. Below are Security User Stories specific to iOS development:

“As a user, I want all sensitive information (e.g., authentication tokens) to be stored in the iOS Keychain, so that my data is protected from unauthorized access.”
“As a system, I want to ensure that network communication is secured using TLS 1.2 or above, to protect against man-in-the-middle attacks.”
“As a user, I want to enable Face ID for sensitive transactions (e.g., payments), to ensure that unauthorized users cannot perform critical actions.”
“As a developer, I want to implement App Transport Security (ATS) to ensure all connections are encrypted.”

Conclusion

Security User Stories are a powerful tool for developers to integrate security into their development process. By writing clear, actionable stories with defined acceptance criteria, development teams can proactively address security risks while ensuring that they meet functional requirements.

Whether you’re building a web app, Windows software, or mobile applications for Android or iOS, incorporating Security User Stories into the backlog ensures that security remains a priority throughout the SDLC.

With this approach, developers can create secure, reliable software that meets the needs of both the business and the users.

The post How-To create Security User Stories first appeared on Sorin Mustaca on Cybersecurity.