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

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.

My company, Endpoint Cybersecurity, offers consulting on how to prepare for TISAX, ISO27001, NIS2, CSMS and SOC2 audits. It also works with companies to create and deploy a Secure Software Development Lifecycle, with various levels of AI support.
Get in touch with us here: https://www.endpoint-cybersecurity.com/contact/

 

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


© Copyright 2026 Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca - Security & Technology


Want to work with me on this topic?
Check Endpoint Cybersecurity to see the consulting services we offer.

Related Posts

Thoughts on AI and Cybersecurity

Being an CSSLP gives me access to various emails from (ISC)2. One of these announced me that there is a recording of a webinar about AI and Cybersecurity held by Steve Piper from CyberEdge. Very nice presentation of 1h, and I found out that there is a sequel to that on November 1st. My company, […]

So much hype about Chat GPT… here are some facts

So much hype about ChatGPT these days.. But what does it mean? So, I gave it a try … and I created an account. My company, Endpoint Cybersecurity, offers consulting on how to prepare for TISAX, ISO27001, NIS2, CSMS and SOC2 audits. It also works with companies to create and deploy a Secure Software Development […]

Artificial Intelligence vs. Machine Learning

I will write in the future a lot about AI and ML with focus on cybersecurity.  I will mix AI and ML and other terms quite a lot, so I think it is necessary to have a base from where to start. For this reason, I created this page with the basics. I don’t want […]

One thought on “Introduction to the Secure SDLC in the AI-Native world: the reality check”

  1. Pingback: Introduction to the Secure SDLC in the AI-Native world: the reality check - IT Security News

Comments are closed.