Tag Archive for: sdlc

You are here: / / sdlc

Posts

Introduction to the Secure SDLC in the AI-Native world: the reality check

/in

Introduction

This is the very first article from a series of articles that will be merged with the existing SDLC Process “From Idea to Proof of Concept to MVP” previously written, finally to be rewritten in an AI-Native SDLC.

 

What is an “AI-Native” organization?

“AI-Native” describes an organization that has restructured how it works around AI as a default part of its processes and tooling, rather than treating AI as an add-on bolted onto existing workflows. The distinction usually drawn is between a company that uses AI tools here and there for individual tasks and one where AI is embedded into how decisions get made, how work gets planned, and how output gets produced and reviewed at a structural level. In practice this shows up as things like AI participating in planning and estimation, AI-assisted code and content generation being a normal step in production rather than an occasional shortcut, and teams and processes being redesigned so that human judgment concentrates on review, direction-setting, and accountability while repetitive execution shifts toward AI. It’s worth being clear that “AI-Native” is more of an aspirational framing used by consultants, vendors, and maturity-model frameworks than a term with one settled, universally agreed definition or an independent body of evidence behind it, so different frameworks describe the destination somewhat differently, and a company calling itself AI-Native today is making a claim about its operating model, not citing a fixed technical standard.

 

Where this stands right now

Adoption numbers of AI are still modest, whatever the marketing around AI-native engineering suggests. The OECD’s SME AI adoption paper, published in December 2025, puts AI use among EU enterprises with 10 or more employees at 13.5 percent in 2024, a figure that had grown 60 percent from the year before. Korea, Denmark, and Sweden lead with adoption above 25 percent, while Hungary sit under 4 percent. Small firms across the OECD median at just 8.5 percent.

The United States shows a similar order of magnitude. The Census Bureau’s Business Trends and Outlook Survey put firm-level AI adoption at roughly 18 percent by the end of 2025, with usage hovering between 17 and 20 percent through the following months. Adoption skews heavily by company size: firms with 250 or more employees report adoption near 37 percent, while businesses under 20 employees stay under 20 percent with little movement. A Federal Reserve note on the same data pointed out that different survey methods produce very different headlines. Weight the numbers by employment instead of by firm count, and the share of the US workforce at AI-adopting companies jumps to 78 percent, because large employers over-represent in the workforce count even though they’re a minority of firms.

Put those two data points side by side and the takeaway isn’t that the US is racing ahead of Europe or vice versa. Both regions sit in the 10-25% for firm-level adoption, with large enterprises far out in front and small and mid-sized companies lagging by a wide margin.

That gap matters for this study, because SSDLC practice has historically been something larger, better-resourced engineering organizations do more rigorously than smaller ones do, and AI tooling is following the same adoption curve rather than flattening it.

Human Roles vs AI in an SDLC

What the classical roles actually do in an SDLC

Before asking which roles AI might replace, it’s worth being precise about what each one is actually responsible for inside a secure development lifecycle. Job titles vary by company, but the underlying accountabilities are fairly stable across the industry.

A Developer writes the code, and in a security-conscious organization that also means threat-modeling their own change at a small scale, following secure coding standards, running static analysis and addressing what it flags, writing tests that cover both functional and abuse cases, and responding to the questions a reviewer raises. NIST’s Secure Software Development Framework treats developers as one node among several who share responsibility for producing and maintaining secure code, not as the sole owner of security outcomes.

A Team Lead sits closest to the code and closest to the people writing it. They review pull requests, arbitrate technical disagreements, make the day-to-day call on what’s good enough to ship, and translate security policy into something a five- or eight-person team can actually follow without slowing to a crawl. They’re usually the first line of defense against both bad code and unrealistic deadlines.

An Engineering Manager owns people and delivery capacity rather than any single codebase. They staff projects, set technical direction at a level above individual features, negotiate timelines with product, and are accountable when a team consistently ships insecure or unstable software, even if they never personally reviewed the offending commit. In a mature SSDLC, they’re the one who has to defend security investment against a roadmap that always wants more features faster.

A Product Manager decides what gets built and in what order, working from customer needs, market pressure, and business goals. Security enters their world as a non-functional requirement they have to weigh against features that visibly move revenue or retention. A product manager who treats security stories as optional, rather than as a normal part of the backlog, is one of the more common root causes behind software that ships insecure by default.

A Program Manager, sometimes called a technical program manager, coordinates work across multiple teams toward a shared deadline or shared dependency chain. They don’t usually write code or make product calls. Instead, they make sure the pieces from different teams land in the right order, that risks get escalated before they become incidents, and that a security requirement owned by one team doesn’t get silently dropped because it wasn’t anyone’s job to track it across a handoff.

A Designer, usually a UX or product designer rather than a graphic designer, sits between the product manager’s requirements and the developer’s implementation, translating what needs to get built into how it should actually work and look for the people using it. Their responsibilities typically span user research (interviews, usability testing, understanding actual user behavior rather than assumptions), information architecture and interaction design (how screens and flows connect, what happens on each state and edge case), producing wireframes and prototypes that get validated before code gets written, and maintaining or contributing to a design system so the product stays consistent as it grows. Designers work closely with product managers on the “what” and “why” and with developers on the “how,” often sitting in on sprint planning and reviewing implemented features against the design intent before release, which puts them in the loop earlier than testing but later than pure strategy.

For the sake or improving the readiness of this article, I skipped many roles found in companies: architect, project manager, release manager, security manager, and many more.

None of these six roles is purely technical, purely creative or purely managerial. They overlap deliberately, and the overlap is where security responsibility usually gets lost when organizations aren’t careful about defining who owns what.

Which of these roles AI can realistically take over, and why

Judged honestly, current AI systems are strongest at tasks with a narrow, well-defined scope and a fast feedback loop, and weakest at judgment calls that require weighing incomplete information against organizational politics, budget, and long-term consequences. That split maps fairly cleanly onto the six roles above.

The Developer role is where AI has made the most real inroads, and it’s not close. Code-completion and agentic coding tools can generate working code, write boilerplate tests, refactor within a defined scope, and increasingly handle small, well-scoped tickets end to end with limited supervision. This is genuine capability, not hype. It’s also bounded: these tools still perform worse on tasks that require deep familiarity with a large, idiosyncratic codebase, and they don’t carry accountability for what they produce. A junior-to-mid-level developer role focused on well-specified, repetitive implementation work is the most exposed to reduction, not elimination, because someone still has to specify the work, review it, and answer for it when it breaks in production.

The Team Lead role is only partially exposed. AI can draft a first-pass code review, flag obvious style or security issues, and summarize a pull request for a human reviewer, which measurably speeds up the mechanical parts of the job. What it can’t do is the part that actually defines the role: knowing which of two competent engineers should own a contested design decision, judging when a shortcut is acceptable given a specific deadline and a specific team’s track record, or having the difficult conversation with someone whose code quality has been slipping. That’s a role AI assists rather than replaces.

Program management is the role most vulnerable in relative terms, and this deserves more caution than the developer point, because it rests less on hard data and more on a structural observation: much of the job is tracking dependencies, chasing status updates, flagging schedule risk, and producing status reports, all tasks an AI agent with access to a company’s ticketing, calendar, and messaging systems can plausibly do today or very soon. What AI structurally cannot do is take organizational accountability. When a cross-team commitment slips and someone has to explain to leadership why, and negotiate a recovery plan that survives contact with three other teams’ competing priorities, that’s a job for a person with standing in the organization, not a tool. Companies that reduce program management headcount because of AI are, realistically, redistributing that accountability onto engineering managers rather than eliminating the need for it.

Product management and engineering management are the least exposed, and for a specific reason: both roles exist primarily to make decisions under genuine uncertainty, where the inputs are ambiguous, political, and often deliberately withheld by other parties in a negotiation. AI can synthesize customer feedback, draft specs, model trade-offs, and summarize competitive research faster than a human, all of which is useful. It cannot own the decision, and in most organizations, legally and practically, someone has to. This is also where the ownership problem discussed below becomes sharpest: a product manager or engineering manager can be held accountable in a way a model cannot, and that asymmetry alone puts a ceiling on how much of these roles gets automated regardless of how capable the underlying technology becomes.

For the Designer, applying the same standard used for the other roles, AI is currently strong at the mechanical output of design work and weak at the parts that require actually understanding a specific set of users. Generating wireframes, component variations, and even reasonably polished UI mockups from a text prompt or an existing design system is something current tools do well and quickly, tools like Figma’s AI features or Claude Design,, and similar generative design tools produce usable starting points in seconds that used to take a designer hours. Where this breaks down is user research: AI can synthesize existing feedback or summarize a pile of usability test transcripts, but it cannot observe a real user getting confused, ask a good follow-up question in an interview, or notice a behavior nobody thought to ask about, because that requires being present with actual people rather than pattern-matching against existing data. It also breaks down on judgment calls specific to a product’s actual users and actual constraints, deciding that a flow needs an extra confirmation step because your specific user base makes a specific kind of costly mistake is a decision grounded in knowledge of those people, not something a model can infer from a generic prompt.

Across all six roles, the summary is that AI is currently good at doing parts of jobs, not entire jobs, and the parts it’s worst at are consistently the parts involving accountability, ambiguity, and interpersonal judgment. Claims that any of these roles will be “replaced” in full within the next few years aren’t supported by what these systems can currently do, and predicting otherwise would be speculation dressed up as forecasting.

What it actually costs, and why the comparison is harder than it looks

A naive cost comparison between AI tools and salaried employees produces a number so lopsided it’s almost meaningless on its own, so I decided to not even write here the numbers my agent researched about both sides.

On the AI side, current subscription pricing for coding tools looks trivial by comparison. GitHub Copilot runs from $10 a month for an individual Pro seat up to $39 for Pro+ and $100 for its Max tier. Cursor’s team plan starts around $40 per user per month. Claude’s team seats run $20 to $25 a month for a standard seat and $100 to $125 for a premium seat with heavier usage. Devin, an autonomous coding agent from Cognition, is a useful case study in how unstable these numbers still are: it launched in 2024 at $500 a month per user, then cut its entry price to $20 a month with pay-as-you-go usage billing in April 2025, a 96 percent drop in list price in about a year. That volatility alone should make anyone cautious about locking a long-term staffing plan to today’s AI pricing.

Comparing a $20-to-$40-a-month subscription to a six-figure salary and concluding AI is a thousand times cheaper is the kind of number that sounds compelling and is also misleading. It compares a flat consumer subscription against fully loaded employee cost, ignoring that heavy agentic use at production scale is billed by token consumption on top of any seat fee, and that cost climbs really fast once an agent or a pod of agents are running many tasks a day against a large codebase rather than assisting one developer occasionally. It also ignores that none of these subscriptions include the human time still required to specify tasks, review output, and take responsibility for what ships, which doesn’t disappear, it shifts.

A more honest framing is that AI tooling lowers the cost of a unit of implementation work meaningfully, likely by a wide margin for well-scoped tasks, while the cost of judgment, review, and accountability stays with people and doesn’t compress at anywhere close to the same rate.

Anyone selling a straight per-seat cost comparison as the basis for a headcount decision is oversimplifying a genuinely complicated tradeoff.

If you work in or with a medium-large company, you most definitely have heard (and felt) by now that people are less production when they run out of tokens or budget for AI API. I’ve even seen people who stopped doing work entirely because their work was exclusively dependent on the AI.

The problems nobody has (fully) solved

The Ownership problem

Secure software development has always rested on a chain of accountability: someone wrote the code, someone reviewed it, someone approved the release, and if something goes wrong, that chain tells you where to look. AI-assisted development strains that chain without breaking it outright, and the strain shows up in a few concrete places.

When an AI agent generates a function that ships with a vulnerability, responsibility doesn’t transfer to the tool. It stays with whoever accepted the change, and behind them, whoever set the review standard that let it through. That’s not new in principle. Code review has always meant a human accepts responsibility for code they didn’t personally write when they approve someone else’s pull request, but the volume changes the practical reality. A reviewer who could reasonably read and understand every line from a human teammate producing a normal day’s output is in a different position when an agent can produce that same teammate’s weekly output before lunch. Review capacity hasn’t scaled at the same rate as generation capacity, and that mismatch is where accountability quietly erodes even though no one decided to lower the bar.

Regulation is starting to catch up to this gap, at least in Europe. The EU’s Cyber Resilience Act, which entered into force on December 10, 2024, with vulnerability reporting obligations starting September 2026 and full applicability by December 2027, puts security-by-design and vulnerability handling duties directly on manufacturers of products with digital elements, meaning a company, not a tool vendor and not an AI system, carries legal liability for what ships.

That’s a useful anchor for this discussion: whatever role AI plays in producing the code, the CRA and comparable frameworks assign the obligation to a legal person, which in practice means it lands on the product manager who approved the feature, the engineering manager who staffed the team, or the executive who signed off on the release process. Ownership doesn’t dissolve into the AI supply chain. It concentrates on whoever’s name is on the compliance filing.

The second ownership problem is subtler and gets less attention: origin. When a change comes from an AI agent trained on a mix of licensed, open-source, and possibly improperly sourced code, questions about IP ownership and license compliance follow the code into your repository, and most organizations don’t yet have a clean answer for how to audit that. This is a real gap, not a hypothetical one, but it’s also not the focus of this study, and claiming certainty about how it will resolve legally would be guessing.

The large-change problem

One of the more concrete, currently measurable concerns about AI-generated code doesn’t come from theory. It comes from repository analysis. GitClear’s 2025 research, based on roughly 211 million lines of changed code from 2020 through 2024, found that the share of copy-pasted code in commits rose from 8.3 percent in 2021 to 12.3 percent by 2024, a roughly fourfold increase in code cloning, and that this was the first year copy-pasted code exceeded moved (that is, refactored and reused) code as a share of changes. Over the same period, refactoring activity dropped from about 25 percent of changed lines to under 10 percent. Put plainly: AI-assisted development is correlating with more code being duplicated rather than reused, and less time spent cleaning up what’s already there.

Google’s DORA research told a related story in its 2024 State of DevOps report: AI adoption measurably increases individual developer productivity, flow, and reported job satisfaction, but it also has a negative association with software delivery stability and throughput at the team level. The report’s own conclusion is worth repeating rather than paraphrasing loosely, because it resists the instinct to treat AI as an unqualified win: teams still need small batch sizes and strong automated testing for AI adoption to pay off, and skipping those fundamentals while adding AI tends to make instability worse, not better.

This is the practical version of the large-change concern raised at the outset. A human developer fixing a bug or adding a feature typically produces a change scoped tightly to that problem, in part because writing more code by hand costs more effort, which is itself a natural brake on unnecessary changes. An AI agent doesn’t share that constraint. Left without tight instructions, it can regenerate a function instead of patching three lines, restructure a file that didn’t need restructuring, or produce a pull request that touches far more surface area than the underlying problem required.

For a normal engineering team this is mostly a productivity and maintainability issue. For a team operating under SSDLC discipline, it’s a security issue too, because every additional line of unnecessary change is additional surface a reviewer has to reason about, additional code that could introduce a new vulnerability unrelated to the original task, and additional material that pull-request-based security gates, which were designed around human-sized diffs, weren’t built to handle efficiently.

The fix isn’t rocket-science: create tightly scoped prompts, diff-size limits enforced in CI/CD, and review processes that explicitly budget more time per AI-touched line than per human-touched line. But it does mean SSDLC processes calibrated for human-paced development need deliberate recalibration, not a simple bolt-on, before AI-generated changes flow through them safely.

Viewing everything through the security lens

The first is (security) review capacity, already touched on above but worth stating as a standalone risk: if AI increases the volume of proposed changes faster than an organization can proportionally increase qualified review capacity, the SSDLC’s central control, human review before merge, degrades quietly (who can review a few hundred to a few thousand lines of code?). Tools that pre-screen pull requests for common vulnerability classes, flag deviations from secure coding standards, and cross-reference changes against known-bad patterns can catch a meaningful share of routine issues before a human ever looks at the diff. That’s a legitimate use of AI inside the SSDLC, not a replacement for review but a filter that makes human review time go further. It is not a substitute for a qualified person understanding why a change is safe, because current tools still miss business-logic flaws, subtle authorization bugs, and anything that requires understanding intent rather than pattern-matching against known vulnerability signatures.

The second is threat modeling. This has always been a weak point in real-world SSDLC practice, done thoroughly by well-resourced teams and skipped or rushed everywhere else, and AI-generated code makes the gap more costly rather than closing it. An AI agent implementing a feature has no inherent model of your system’s trust boundaries, and it will happily generate code that’s locally correct while violating an assumption three services away that it has no way of knowing about. AI can assist with threat modeling, drafting a first-pass data flow diagram or suggesting the standard threats for a common pattern like an authentication endpoint, but the exercise of defining trust boundaries for a specific system still needs someone who understands that system’s actual architecture and actual attackers, not just the generic case.

The third is dependency and supply chain risk, and here AI cuts both ways more clearly than anywhere else in this study. AI coding tools frequently pull in third-party packages to solve a problem quickly, sometimes packages the requesting developer or his organization has never evaluated, which is a direct path to the kind of software supply chain risk that frameworks like the NIST SSDF and the CRA specifically target. At the same time, AI-driven software composition analysis is one of the more mature and genuinely useful security applications available today: automated dependency scanning, license checking, and known-vulnerability matching against something like a software bill of materials are tasks AI and traditional automation both handle well, arguably better than a human doing it manually, because the problem is pattern-matching against a large, structured dataset rather than exercising judgment.

The fourth is secrets and credential handling. AI-assisted code generation has a documented tendency to reproduce patterns it’s seen in training or context, including hardcoded credentials, overly permissive default configurations, and insecure examples lifted from documentation that was never meant for production use. Automated secret-scanning in CI pipelines addresses this reasonably well and should be considered close to mandatory in any AI-assisted workflow, not optional hardening.

The fifth, and the one most directly tied to the ownership discussion above, is audit trail integrity. When responsibility for a security incident needs to be reconstructed, an organization needs to know not just what changed but who or what proposed it, who reviewed it, and on what basis it was approved. Many teams adopting AI coding tools haven’t yet updated their change-tracking to distinguish AI-authored contributions from human-authored ones in a way that would hold up under a real incident investigation or a regulatory audit under something like the CRA. This is a solvable process gap, not a technology limitation, and it’s one of the more actionable items an organization can fix regardless of how the higher-level AI adoption debate resolves.

Across all five of these, the pattern repeats: AI is a legitimately strong addition to the mechanical, pattern-matching layer of SSDLC, the parts of the process that were always partly about processing volume and consistency. It is not yet, and on current evidence shouldn’t be trusted as, a replacement for the judgment layer, the part of SSDLC that depends on someone understanding a specific system, a specific threat environment, and a specific organization’s risk tolerance well enough to make a defensible call and stand behind it.

Where this leaves the AI-Native ambition

None of this argues against AI adoption in software development, and it shouldn’t be read that way. The productivity data is real, the tooling is improving quickly, and organizations that ignore it will fall behind those that use it well. But the specific framing of AI-Native as a wholesale replacement for classical engineering roles doesn’t hold up against either the adoption data or the capability evidence available right now. Adoption is still concentrated in large firms and still sits under 20 percent even there. The roles most exposed, developer implementation work and parts of program coordination, are exposed to significant augmentation and some headcount pressure, not elimination, because the accountability those roles carry doesn’t transfer to a model no matter how capable it becomes. And the security discipline this study set out to examine gets harder in specific, nameable ways before AI makes it easier, chiefly through review capacity strain and larger, less-scoped changes, even as AI genuinely helps with the more mechanical parts of the same discipline, like dependency scanning and first-pass code review.

The realistic path for most organizations is narrower and less dramatic than either the AI-replaces-engineering narrative or the AI-changes-nothing narrative suggests: use AI to compress the mechanical, high-volume parts of secure development, keep human ownership explicit and traceable for everything that involves judgment or carries legal accountability, and treat the SSDLC controls built for human-paced change as something that needs deliberate rework, not a simple bolt-on, before they can be trusted to hold at AI-assisted speed.

 

Sources

The post Introduction to the Secure SDLC in the AI-Native world: the reality check first appeared on Sorin Mustaca – Security & Technology.

Why SSDLC is helping shipping faster and more secure code

/in

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

/in

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

/in

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

/in

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:

  1. 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.
  2. Clear Requirements for Developers: Security User Stories provide clear, actionable security requirements, helping developers understand exactly what is expected to make the software secure.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Portfolio Items