Tag Archive for: ssdlc

You are here: / / ssdlc

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.

EU Cyber Resilience Act (CRA) – Overview

/in

What is the Cyber Resilience Act – CRA

The Cyber Resilience Act is the first European regulation to set a mandatory minimum level of cyber security for all connected products available on the EU market – something that did not exist before.

The CRA is a regulation from the European Union — formally Regulation (EU) 2024/2847 — but it is likely to be applied soon in other parts of the world, which produce for and sell products in the EU.

It covers both hardware and software products whose intended or foreseeable use involves connection (direct or indirect) to a device or network. That includes things like smartphones, laptops, IoT devices (smart-home cameras, smart fridges, connected toys), embedded systems, routers, industrial control systems, and even software with network connectivity.

Non-commercial open source software products are exempt from the CRA and therefore do not have to fulfill the requirements of the CRA.

Some product categories are excluded because they are already covered by other sector-specific regulation (e.g. certain medical devices, aviation, automotive, defense).

As can be seen, the aim is to increase cybersecurity within the European Union. The new regulation applies in all EU Member States and will be implemented gradually.

Timeline & Legal Effect

The CRA entered into force on 10 December 2024. There is a transition / compliance period: the full requirements become applicable by 11 December 2027 for new products.

Starting 11 June 2026, the Conformity Assessment Bodies can assess the fulfillment of the requirements.

Reporting of vulnerabilities and security incidents starts on 11 September 2026.

*CABs = Conformity Assessment Bodies

Source: BSI

Key Requirements & Obligations

For manufacturers, importers or distributors of in-scope products, CRA demands:

Secure-by-design and secure-by-default

During design and development, implement baseline cybersecurity controls (minimizing attack surface, secure defaults, applying cryptography, access control, integrity protection, etc.).

If you design or manufacture hardware or software intended for the EU market — start including security early: threat modelling, secure defaults, update mechanisms, patch management, SBOM (software-bill-of-materials) for components, documentation.

Lifecycle security

Maintain security across the lifecycle — through production, deployment, maintenance, updates (patches), and eventual decommissioning.

Prepare to collect and maintain documentation of the build, supply chain components, update/maintenance history, and test results for many years.

Vulnerability & incident reporting

If a product becomes subject to a “actively exploited vulnerability” or a “severe security incident”, the manufacturer must report promptly (early warning within 24 h, full notification within 72 h, final report within certain timeframes) via the CRA Single Reporting Platform.

For software vendors — ensure update/patch infrastructure is robust and built-in, and notification processes in place for vulnerabilities.

Documentation & traceability

Maintain technical documentation, data inventories and evidence of security measures for a defined period (often many years) after placing the product on the market.

CE-marking with security

Products that comply must carry the CE-mark, indicating conformity with the CRA’s cybersecurity requirements — similar to CE marking for safety or environmental compliance.

For buyers/customers — expect CE-mark + transparency regarding security posture. Choose vendors who commit to long-term patching and vulnerability response.

Conformity assessments for higher-risk products

While many products (roughly 90%) fall under a “default” tier and can be self-assessed by manufacturers, certain more critical or important product types (e.g. firewalls, security modules, intrusion detection systems, certain embedded systems) may require third-party assessment before being placed on market.

Why It Matters

The CRA establishes a common, EU-wide baseline for cybersecurity of digital products. This helps avoid fragmentation where different member states might otherwise have different rules. It forces manufacturers and vendors to adopt security by default + lifecycle security, rather than treating cybersecurity as an optional afterthought. This helps reduce the attack surface and improves resilience against cyber threats.

It increases transparency for consumers and businesses: when they buy a product with digital elements, they can expect a baseline of security and support — including updates and vulnerability management.

For vendors and developers — in enterprise, embedded, IoT or consumer space — it’s a legal obligation. Non-compliance when required could lead to regulatory consequences, and non-compliant products will not be allowed on the EU market once the deadlines lapse.

 

CRA Product Classification

Criteria & Examples

The CRA divides “products with digital elements (PDEs)” into four classification tiers. Classification drives what conformity assessment, certification, and compliance rigour you must apply.

Category When a product is placed here (criteria / rationale) Typical product examples*
Default Products that are not listed in the “Important” or “Critical” annexes — i.e. no particularly sensitive cybersecurity function or high risks associated with compromise. Many consumer devices & software: smart toys, basic IoT devices, simple smart-home equipment, non-security-critical apps, common consumer electronics.
Important – Class I PDEs that provide a cybersecurity-relevant function (authentication, access control, network access, system functions) but whose compromise would have a moderate risk (less than Class II). Identity management systems / privileged-access software or hardware (e.g. access readers), standalone/embedded browsers, password managers, VPN clients, network management tools, operating systems, microcontrollers/microprocessors with security-related functions, routers/modems/switches.
Important – Class II PDEs whose function involves a significant cybersecurity risk, or whose compromise could have wide or severe impact, especially on many other systems — thus higher criticality than Class I. For these, third-party conformity assessment is mandatory. Firewalls, intrusion detection/prevention systems (IDS/IPS), virtualisation/hypervisor/ container runtime systems, tamper-resistant microprocessors/microcontrollers, industrial-grade network/security systems.
Critical PDEs with cybersecurity-related functionality whose compromise could disrupt or control a large number of other products, critical infrastructure, supply chains or sensitive services. These must either get an EU cybersecurity certificate (per relevant scheme) or undergo strict third-party assessment. Hardware security modules (“security boxes”), smart meter gateways, smartcards / secure-elements, secure cryptoprocessing hardware — i.e. devices central to critical infrastructure, secure identity, secure communication or supply chain security.

* These examples reflect currently published annex examples and guidance. Regulatory technical specification updates (e.g. by the European Commission) may refine or expand the lists.

 

Assessment & conformity requirements per class

Below are examples of software products affected by the Cyber Resilience Act, organized into two tables and classified into the CRA categories:

  • Default Category – non-critical, low inherent risk

  • Important Class I – higher exposure, widely deployed, could be abused at scale

  • Important Class II – products with elevated security relevance, including security software and products in Annex III

  • Critical – core components of cybersecurity, identity, encryption, or essential network infrastructure

These classifications follow the CRA’s conceptual tiers, not an official certification list, because exact classification depends on the manufacturer’s intended use and applicability of Annex III.

Examples of Software Products Classification

Disclaimer: this is my current understanding of products with digital elements (PDEs). There is no official list of categories of products published, or at least I did not find one.

This list was created with help of AI and it is no guarantee to be complete or correct.

 

Software Type Example(s) CRA Category Rationale
CRM Platforms Salesforce, HubSpot, MS Dynamics Default General business software; no direct security function.
Blogging/CMS Platforms WordPress, Ghost, Drupal Default Consumer and enterprise web software; not security-critical by default.
Office Productivity Tools LibreOffice, MS Office Default Widely used but not security components.
Developer Tools IDEs, build systems Important Class I Used in software supply chains; compromise impacts downstream.
Cloud Management Consoles AWS CLI tools, Azure Portal extensions Important Class I Access to infrastructure; security implications.
Antivirus / Endpoint Protection CrowdStrike, Defender, Bitdefender Important Class II Security products explicitly listed under risk-sensitive categories.
EDR/XDR Platforms SentinelOne, Trellix, Microsoft XDR Important Class II Security monitoring and threat response capabilities.
Firewalls (Software-based) pfSense, OPNsense, Cisco, Juniper Important Class II Security enforcement components.
VPN Clients OpenVPN Client, WireGuard clients Important Class II Encryption and secure communications; directly covered.
Identity & Access Software SSO, MFA clients, IdP agents Critical Core identity systems; high systemic impact.
Key Management & Crypto Libraries OpenSSL, libsodium Critical Cryptographic primitives/implementations; part of critical components.
Secure Configuration Agents MDM agents, compliance agents Important Class II Affect system posture and policy enforcement.
Network Monitoring / SIEM Splunk, Elastic, QRadar Important Class II Security event analysis and detection.
Container Security Tools Aqua, Twistlock Important Class II Protect containerized workloads; tied to infrastructure security.

 

Further reading and sources

The post EU Cyber Resilience Act (CRA) – Overview first appeared on Sorin Mustaca’s blog.

From Idea to Proof of Concept to MVP: The Minimum Viable Product – MVP (3/3)

/in

We continue the series of 3 articles with the second one, about the Minimum Viable Product (MVP).

Here is the first article in the series, From Idea to Proof of Concept to MVP: The Idea stage (1/3) and the second article, the From Idea to Proof of Concept to MVP: The POC stage (2/3) .

3. The Minimum Viable Product (MVP)

Once the team has validated feasibility, the work shifts to building a usable, reliable product with a minimal but complete set of features.
The MVP is the first version that serves real users and collects real feedback.

Code quality, architecture, and processes now matter because the MVP becomes the foundation for all future iterations.

Purpose and Scope

The MVP implements the core value with enough stability, scalability, and security to run in production.
It does not include every possible feature—only the essentials—but it must be well-engineered.

Inputs and Outputs

Inputs include the validated POC, UX designs, refined requirements, and mandatory security needs.
Outputs include a deployable product, operational metrics, user feedback, and a backlog for enhancements.

Actors

The full engineering team is involved: backend, frontend, QA, DevOps, Security, UX, Product, and Operations.
Cross-team communication becomes essential, because making the MVP stable requires alignment across all disciplines.

Engineering Expectations at This Stage

Code Quality and Reuse

Developers now take the core logic from the POC and turn it into production-ready modules.
This involves consistent naming, clear responsibilities, robust error handling, schema validation, and test coverage.
The team extracts reusable libraries, shared components, or service interfaces to avoid future duplication.
The MVP becomes the beginning of a long-term codebase.

Required Technical Changes

  • Transform API drafts into versioned, documented REST or GraphQL interfaces.

  • Move throwaway scripts into properly structured modules or services.

  • Add input validation, sanitization, and schema enforcement.

  • Introduce unit tests, integration tests, and E2E tests.

  • Replace temporary mock data with real data pipelines.

  • Add observability: logs, metrics, traces, dashboards.

  • Integrate with continuous delivery pipelines.

Process Evolution

The team adopts formal processes:

  • CI/CD, code reviews with defined guidelines, branching strategies, automated testing, deployment checklists, and observability standards.
  • Documentation becomes mandatory because the product is no longer experimental.

Backend Example

The recommendation engine becomes now a stable service.
The POC endpoint turns into a versioned API with full request validation, structured logging, retry logic, error mapping, and test coverage.
The integration with the ML service now uses proper authentication, rate limiting, and timeouts.
Monitoring dashboards track latency, throughput, and error rates.

Frontend Example

The rough POC component becomes part of the application’s design system.
It uses reusable UI components, handles loading and error states gracefully, and integrates with the global state store.
Unit tests confirm component behavior, tests validate the full user flow.
Telemetry captures user interactions so the team can validate assumptions after launch.

Security

Security now moves from conceptual and experimental checks to real, enforceable controls.
This includes:

  • Authentication and authorization integration

  • Input validation and output encoding

  • Protection against injection vulnerabilities

  • HTTPS enforcement and secure cookie settings

  • Audit logging

  • Secrets management

  • Data-handling guarantees for sensitive information

The MVP does not need every advanced security feature, but it must meet the minimum standards required for production—especially if it processes personal or regulated data.

Here is the first article in the series, From Idea to Proof of Concept to MVP: The Idea stage (1/3) and the second article, the From Idea to Proof of Concept to MVP: The POC stage (2/3) .

The post From Idea to Proof of Concept to MVP: The Minimum Viable Product – MVP (3/3) first appeared on Sorin Mustaca’s blog.

Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery

/in

Click below for the podcast version (AI generated):

Guide for delivering frequently software features that matter: the three Pillars of successful frequent delivery

If you’re a software engineer older than 30 years, then you definitely have worked following a non-agile methodology.

Those methodologies are based on a fixed structure, a lot of planning, and hope that everything will go as planned. And they never worked 🙂

 

Small bets, less risk

After helping many teams transform their delivery approach over the past 2 decades, I’ve learned that the most successful software projects share one trait: they deliver working software early and often. Think of it like learning to cook—you taste as you go rather than waiting until the entire meal is prepared to discover it needs salt – or to discover that it has too much salt.

Scrum’s power lies in its ability to turn software development from a high-stakes gamble into a series of small, manageable bets.  It basically lowers the risk of creating something that is a failure before it is even released.

Instead of spending months building features that might miss the mark, you deliver value every 2 weeks and course-correct based on real user/stakeholder feedback.

 

The Three Pillars of successful frequent delivery

1. Sprint Planning that actually delivers value

Here’s where most teams go wrong: they focus on completing tasks instead of delivering outcomes.

In my experience, the magic question that transforms Sprint planning is: “What could we deliver to users at the end of this Sprint that would make them say ‘this is useful’?”

Or maybe, if you’re not that far, think in terms of: what do we have to do in order to be able to have something to show to customers/users/stakeholders?

This shift in thinking leads to what I call “vertical slicing”—delivering complete, end-to-end functionality rather than building in horizontal layers.

Think of instead of spending a sprint on “database framework,” you deliver a complete feature like “user login” that touches database, business logic, and user interface.

Or, instead of having a “GUI framework”, implement a GUI element and make it testable. You will still need to put the base of the GUI framework, but you will likely (or hopefully) implement only those elements needed to deliver that one element.

 

2. Your Definition of Done (DoD) is your safety net

The Definition of Done isn’t bureaucracy—it’s your insurance policy against the dreaded “90% complete” syndrome. I’ve seen too many teams rush to demo features that weren’t actually ready for users, creating technical debt that haunts them for months.

A solid Definition of Done includes peer reviews, automated tests, security checks, performance validation, and sometimes stakeholder approval.

Think of it as your quality gateway: nothing passes through unless it meets production standards.

 

3. What enables speed

CI/CD

Continuous Integration isn’t just a nice-to-have—it’s the foundation that makes frequent delivery possible. When code is integrated and tested multiple times, you eliminate the integration nightmares that plague traditional development.

Anything that is manual, especially testing, takes more time on the long run. And in software development you are running a multi stage marathon. Invest in automated End-To-End testing and you invest the time once, not every release cycle.

 

Main branch development

The teams who excel at frequent delivery have embraced “trunk-based development” where everyone works from the main branch. This forces smaller, more frequent commits and prevents the merge conflicts that can derail Sprint goals.

You might say that this is not always possible – and I even agree. Sometimes you need to branch in order to allow parallel development of larger features, which you don’t want to deliver step-by-step. While I don’t like this approach, I understand that sometimes it makes sense.

But, even in such cases, you can apply the same strategy on the parallel branch: make many small commits so that you can release often and test often.

 

I’ll stop here for now, but as you can see, there are many challenges that stop teams from releasing often.

I’ll address this in the next article from this series.

The post Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery first appeared on Sorin Mustaca on Cybersecurity.

Guide for delivering frequently software features that matter (series)

/in

If you’re a software engineer older than 30 years, then you definitely have worked following a non-agile methodology.

Those methodologies are based on a fixed structure, a lot of planning, and hope that everything will go as planned. And they never worked 🙂

 

Small bets, less risk

After helping many teams transform their delivery approach over the past 2 decades, I’ve learned that the most successful software projects share one trait: they deliver working software early and often. Think of it like learning to cook—you taste as you go rather than waiting until the entire meal is prepared to discover it needs salt – or to discover that it has too much salt.

Scrum’s power lies in its ability to turn software development from a high-stakes gamble into a series of small, manageable bets.  It basically lowers the risk of creating something that is a failure before it is even released.

Instead of spending months building features that might miss the mark, you deliver value every 2 weeks and course-correct based on real user/stakeholder feedback.

 

The Three Pillars of successful frequent delivery

1. Sprint Planning that actually delivers value

Here’s where most teams go wrong: they focus on completing tasks instead of delivering outcomes.

In my experience, the magic question that transforms Sprint planning is: “What could we deliver to users at the end of this Sprint that would make them say ‘this is useful’?”

Or maybe, if you’re not that far, think in terms of: what do we have to do in order to be able to have something to show to customers/users/stakeholders?

This shift in thinking leads to what I call “vertical slicing”—delivering complete, end-to-end functionality rather than building in horizontal layers.

Think of instead of spending a sprint on “database framework,” you deliver a complete feature like “user login” that touches database, business logic, and user interface.

Or, instead of having a “GUI framework”, implement a GUI element and make it testable. You will still need to put the base of the GUI framework, but you will likely (or hopefully) implement only those elements needed to deliver that one element.

 

2. Your Definition of Done (DoD) is your safety net

The Definition of Done isn’t bureaucracy—it’s your insurance policy against the dreaded “90% complete” syndrome. I’ve seen too many teams rush to demo features that weren’t actually ready for users, creating technical debt that haunts them for months.

A solid Definition of Done includes peer reviews, automated tests, security checks, performance validation, and sometimes stakeholder approval.

Think of it as your quality gateway: nothing passes through unless it meets production standards.

 

3. What enables speed

CI/CD

Continuous Integration isn’t just a nice-to-have—it’s the foundation that makes frequent delivery possible. When code is integrated and tested multiple times, you eliminate the integration nightmares that plague traditional development.

Anything that is manual, especially testing, takes more time on the long run. And in software development you are running a multi stage marathon. Invest in automated End-To-End testing and you invest the time once, not every release cycle.

 

Main branch development

The teams who excel at frequent delivery have embraced “trunk-based development” where everyone works from the main branch. This forces smaller, more frequent commits and prevents the merge conflicts that can derail Sprint goals.

You might say that this is not always possible – and I even agree. Sometimes you need to branch in order to allow parallel development of larger features, which you don’t want to deliver step-by-step. While I don’t like this approach, I understand that sometimes it makes sense.

But, even in such cases, you can apply the same strategy on the parallel branch: make many small commits so that you can release often and test often.

 

I’ll stop here for now, but as you can see, there are many challenges that stop teams from releasing often.

I’ll address this in the next article from this series.

The post Guide for delivering frequently software features that matter (series) first appeared on Sorin Mustaca on Cybersecurity.

AI vs. (secure) software developers

/in

I think the entire software development world saw NVIDIA’s CEO saying that the world will stop needing software developers, because they will be replaced by AI.

Well, considering that this comes from the guy who sells the core on which AI is built, is understandable.

But is there any truth to this? Let’s look at some Strengths and Weaknesses of AI in the field of software development, with focus on secure software development.

 

The Strengths of AI in Software Development

AI excels in automating repetitive tasks and processing vast amounts of data quickly. For example, AI-driven tools can:

  • Identify common vulnerabilities such as SQL injection or cross-site scripting (XSS) using pattern recognition.
  • Suggest code refactoring for improved efficiency or readability.
  • Provide automated testing and validation for specific use cases.
  • Generate code snippets that can speed up development, allowing developers to focus on complex, high-level tasks instead of repetitive tasks.
  • Perform static and dynamic code analysis faster than manual reviews, identifying potential issues across large codebases in a fraction of the time.
  • Offer predictive insights by analyzing historical data to anticipate possible security breaches or performance bottlenecks.
  • Facilitate compliance checks by mapping code against security standards and regulatory requirements.

These capabilities make AI invaluable for enhancing productivity and reducing the burden of mundane tasks. However, AI has limitations that highlight the irreplaceable role of skilled developers.

The Weaknesses of AI in Secure Software Development

  1. Lack of context understanding
    AI tools often struggle to grasp the context of a software system. Security vulnerabilities often stem from contextual issues, such as improper assumptions about user behavior or architectural flaws.
    Developers use their domain knowledge and intuition to identify these issues—something AI cannot replicate.
  2. Overreliance on patterns
    AI relies heavily on training data and pattern recognition. This approach can lead to false positives (flagging issues that aren’t real) and false negatives (missing actual vulnerabilities).
    Developers, on the other hand, use critical thinking to assess risks and prioritize fixes.
  3. Lack of creative problem-solving
    Secure software development often requires innovative solutions to unique problems.
    AI lacks the creativity and adaptability of humans, limiting its ability to design custom security measures.
  4. Ethical and legal implications
    AI cannot make ethical decisions or assess the broader implications of its suggestions.
    Developers with security expertise consider regulatory compliance, ethical concerns, and long-term impact when designing secure systems.
  5. Lack of continuous growth
    Unlike developers, whose experience grows continuously through exposure to new challenges, AI systems remain static unless explicitly retrained.
    Developers improve their skills, adapt to emerging threats, and learn from past experiences, ensuring they stay ahead of evolving security risks.
  6. Limited problem-solving scope
    AI knows only what it was trained with. This limitation means it struggles to address new or unconventional problems that fall outside its training data.
    Developers, by contrast, use their ingenuity and evolving expertise to find innovative solutions to emerging threats and challenges.

 

Examples of AI Mistakes

Here are some scenarios where AI is not mature enough, and developers with security skills excel:

  • Misidentifying Threats: An AI tool might flag a harmless API endpoint as a potential security risk due to pattern similarity, while missing a nuanced logic flaw that allows privilege escalation.
  • Overlooking Complex Dependencies: AI might fail to account for security risks in intricate dependency chains or third-party integrations, where a developer’s experience would highlight potential issues.
  • Generic Recommendations: AI might suggest generic fixes that do not align with the specific architecture or threat model of the application, whereas developers tailor solutions to the system’s needs.
  • Failing to Detect Zero-Day Vulnerabilities: AI cannot identify vulnerabilities that do not have a pre-existing pattern in its training data. Developers’ intuition and expertise are critical for detecting these novel threats.
  • Incorrectly Prioritizing Vulnerabilities: AI might prioritize fixing minor issues over addressing critical risks, leading to inefficient resource allocation. Developers can apply risk-based decision-making to prioritize effectively.
  • Overlooking Business Logic Flaws: AI often fails to detect flaws in the business logic that attackers can exploit. These vulnerabilities require a deep understanding of the application’s purpose and workflows, which developers possess.
  • Inappropriate Code Suggestions: AI-generated code snippets may inadvertently introduce vulnerabilities or fail to comply with specific security policies. Developers review and adapt these snippets to ensure secure integration.
  • Old or obsolete training data: AI recommends very often snippets of code based on old APIs, which might no longer exist by the time it is asked to generate some code. Developers will look always at the latest documentation of the API they need.

 

Instead of conclusions

AI is a powerful tool that enhances the capabilities of developers but, as can be seen above, it does not replace them. At least for a long while … 🙂

The ideal approach is a collaborative one, where AI handles repetitive tasks and provides data-driven insights, allowing developers to focus on high-level problem-solving and decision-making.

Organizations should invest in both AI tools and the continuous development of their teams’ security skills.

This balanced approach ensures that the software remains secure, reliable, and resilient against threats.

 

The post AI vs. (secure) software developers first appeared on Sorin Mustaca on Cybersecurity.

Accelerating feature delivery in software development

/in

My company develops security products for all major operating systems. We work with startups and with big companies, all striving to develop features (functional and non-functional) as fast and as good as possible.

While on the first view this seems like a contradiction, there are actually ways of implementing exactly this.

For security software development teams aiming to deliver features more frequently, streamlined processes and efficient workflows are essential.

You guessed, the keywords are agile methods with the related activities such as automated testing, strategic prioritization, agile delivery, efficient workflows, regular and early feedback.

Below are several approaches that emphasize frequent and reliable delivery.

Define requirements with speed in mind

Clear, concise requirements set a strong foundation for quick delivery. Ensuring each feature has straightforward objectives and well-defined acceptance criteria reduces delays caused by back-and-forth clarifications. For security-focused teams, requirements should include key security considerations without overloading the development process. By clarifying expectations from the start, developers can stay on track, avoiding unnecessary revisions and accelerating overall delivery. This being said, also do not change the direction too often (called Pivoting). If you don’t allow feature to “sit”, the product will never reach maturity.

Setup incremental, agile delivery

Breaking down feature development into small, manageable increments supports faster delivery. Rather than waiting for a full release, an incremental approach allows developers to deliver small updates frequently. This Agile-inspired method brings quick wins, shortens feedback cycles, and lets teams adjust direction as needed based on real-world usage. Incremental delivery ensures that new functionality reaches users sooner, making the product more responsive to changing needs.

Optimize for efficiency

Security doesn’t have to slow down delivery. By embedding secure coding practices into the team’s daily workflows, developers can build security right into each feature rather than adding it at the end. Code reviews focused on security can be streamlined with checklists or automated tools, keeping the process efficient. This “security-first” mindset ensures that features remain secure while minimizing delays, as there’s no need for last-minute security fixes.

Invest in CI/CD

Automated testing is key to quick, reliable feature deployment. Automated tests that cover basic functionality and security requirements provide instant feedback, allowing developers to identify and address issues faster. Implementing continuous integration (CI) tools that automatically trigger these tests during development helps the team validate new features on the go. By automating tests, the team gains more time for development and can release updates with minimal manual intervention.

Integrating DevSecOps practices into the development pipeline enables seamless security without slowing down delivery. Automated security checks within the CI/CD pipeline provide fast, reliable security validations, allowing developers to address issues before deployment. This approach keeps the pipeline moving smoothly, as security checks become an integrated part of the process, rather than an additional step that slows down delivery.

Encourage collaborative and efficient workflow

Encourage open communication between developers, security teams, and testers to streamline workflows. Collaborative sessions for discussing roadblocks or coordinating on shared goals help prevent bottlenecks. An open environment where team members share updates and resolve issues collectively accelerates progress by addressing concerns in real time. By emphasizing collaboration, teams can work faster, catching potential blockers early and adapting quickly to new requirements.

Use regular retrospectives to identify and remove delivery obstacles

Post-release retrospectives focused on delivery efficiency help identify and eliminate roadblocks. By analyzing each release or sprint for delays and other issues, teams can identify specific pain points in the development or deployment process. These retrospective sessions allow the team to adjust practices and improve their ability to deliver quickly, refining the workflow with each iteration.

 

The post Accelerating feature delivery in software development first appeared on Sorin Mustaca on Cybersecurity.