There’s something about AI-assisted coding, or “vibe coding”, that feels eerily familiar. Not familiar in the cozy, “grandma’s kitchen” sense, but familiar like the “oh dear God, haven’t we lived through this before?” way. As someone who has spent 25 years in cybersecurity, but also lived through the heady days of financial services leading up to the 2008 crash, I can’t shake the déjà vu, but I couldn’t find the word to describe it.

Rewind 18 years. Fintechs were booming, balance sheets were exploding, and the market believed in infinite growth because, well, why not? When Bear Stearns collapsed in March 2008, the financial world shrugged and said, “That’s weird, but it’ll buff out.” Then Lehman Brothers imploded in September, and suddenly it wasn’t fine. Cue The Big Short, a Michael Lewis book (and later a hit movie) that let everyone claim they totally understood what Collateralized Debt Obligations (CDOs) and Credit Default Swaps (CDSs) were.

This summer, I attended Stacey Schreft’s talk at B-Sides Las Vegas comparing the 2008 crisis to cybersecurity. She aptly pointed out that the 2008 financial crisis was caused by a number of factors, and one of them was “Leverage”.  That’s the word I had been fumbling for! AI-assisted coding is doing exactly that: it is creating massive leverage for half-baked designs to sprint into production, and it democratizes a skill that often requires nuanced knowledge. And if history is any guide, we may be on the brink of a subprime coding crisis.

Subprime Code and the Illusion of Velocity

Let’s start with the obvious: there’s been an explosion of AI tools that promise to help you code faster: Claude Code, Cursor, Replit, GitHub Copilot, ChatGPT plugins, take your pick. With a keystroke, anyone can generate scaffolding, build APIs, or even deploy entire web or mobile apps. Idea-to-Build-to-Deploy-to-Prod pipelines have never been so frictionless.

And therein lies the leverage. We’ve handed the keys to developers, regardless of skill or experience level, who can now ship “working” software without really understanding what’s under the hood. Just like banks in 2006 handing out no-documentation loans — “you want a $500,000 mortgage with no job, no income, and no clue? Approved!”

Velocity is intoxicating. But velocity without guardrails is risky, like a centrifuge spinning out of control. We’ve already seen it: junior developers proudly demoing AI-generated apps that “just work” until you actually press a few buttons and the thing catches fire. Blue skies today, storm clouds tomorrow.

The financial world had its subprime mortgages bundled into AAA-rated instruments called CDOs. In tech, we’re stuffing subprime code into environments that may also host mission-critical, well-architected systems. And just like those mortgage bundles, the toxic parts don’t stay hidden forever. Eventually, they overwhelm the system.

The Disappearance of the Experts

Here’s the kicker: the people who actually know how to build resilient systems (the software equivalent of conservative bankers) are increasingly being sidelined.

Experts understand full lifecycles: design, build, test, deploy, maintain, decommission. They know how to architect for failure, manage dependencies, and measure resilience. But in the vibe coding world, those experts can be seen as expensive bottlenecks. “Why waste time on design reviews when Copilot can churn out a module in 30 seconds?”

Sound familiar? It should. During the mortgage boom, traditional bankers who insisted on things like income verification were laughed out of the room. Why check pay stubs when the market is only going up?

Subprime code is like the adjustable-rate mortgage of software. Cheap and shiny at first, a maintenance nightmare later. Return on investment looks fantastic on day one: “Look, we shipped in record time!” but the total cost of ownership lurks like a balloon payment.

Tech Debt Interest Rates Rise

Ask any seasoned engineer: all software atrophies. Bugs accumulate. Dependencies rot. Vulnerabilities creep in. Without care and feeding, systems degrade. Historically, experts have played the roles of janitor, custodian, and responsible borrower, patching, refactoring, and paying down the interest on tech debt.

But AI-assisted coding doesn’t do maintenance. It doesn’t monitor environments. It doesn’t patch quietly at 2 a.m. It just creates more code. And more code equals more surface area for entropy.

As technical debt mounts, the “interest rate” rises. Minor bugs turn into cascading failures. Vulnerabilities become attack vectors. Suddenly, those quick wins cost exponentially more to sustain. Just like mortgage defaults snowballed when interest rates reset, defaults in vibe-coded systems will come when organizations can’t keep up with the compounding debt.

The Crash

At first, everything will look fine. Systems will hum, dashboards will glow green, and product managers will beam about how fast they’re shipping.

Then entropy kicks in. Fragility multiplies. That vibe-coded feature you deployed last year? It now breaks every time a library updates. The chatbot you shipped to production? It leaks data under certain inputs. The infrastructure-as-code templates your intern pasted in? They left the equivalent of the front door wide open.

When enough of these brittle systems stack together, the crash comes. Not necessarily one big bang (though don’t rule it out), but more likely a rolling crisis. Outages become more frequent, breaches more severe, and recovery becomes slower. Organizations without experts to bail water will drown in their own subprime code.

The severity of the crash may depend on the ratio of subprime code to prime code, and whether experts have been retained as the last line of defense. Unfortunately, the current trajectory doesn’t inspire confidence, and those experts will likely burn out fighting the fire.

Avoiding the Subprime Code Bubble Burst

So, where do we go from here? Pretending vibe coding doesn’t exist isn’t an option. The genie is out of the bottle, and frankly, there’s enormous potential if we wield it wisely. But just as regulators eventually reined in no-doc loans (a bit too late, admittedly), we need discipline in software development before the crash comes.

1. PoC / R&D is not Production Grade. Develop and experiment with intentionality but plan on doing significant engineering work once that is done to make it production grade.  Don’t let the intoxication of velocity make you forget how to make things resilient and great.
   
2. Architect for resilience, not just features. Build failure modes into the design, not as an afterthought.
   
3. Retain and empower experts. They’re not relics of a bygone era; they’re the guardrails that keep velocity from turning into a crash.
   
4. Don’t forget to train the next generation. While they can build quickly because they don’t know what dangers lurk in prod, they also need to learn how to build well.
   
5. Test like you mean it. Automated frameworks that validate resilience are as critical as the code itself.
   
6. Plan for maintenance up front. If your AI-generated module doesn’t come with a maintenance strategy, then it’s not an asset; it’s a liability.  Don’t focus solely on ROI, but also consider TCO.
   

The temptation will always be to hand AI tools to non-experts and let them sprint. It’s cheaper. It’s faster. It feels like growth. But without expertise, architecture, and discipline, it’s just leverage, and leverage cuts both ways, and it cuts deeper over time.

The 2008 crisis taught us that bubbles don’t last forever, and crashes are far more expensive than resilience. Today, vibe coding gives us incredible speed, but it also risks burying us in a mountain of subprime code. The only question is whether we learn from history or end up explaining to our kids, 10 years from now, why The Big Short 2: Code Harder is topping Netflix.

It’s that time of the year again when we work through the budgeting process, which inevitably takes longer every year than anticipated. Every participant is fighting for their slice of the pie, and the inevitable conversation comes up to figure out whatright amount to spend on Security. No one wants to overspend, but underspending can also be disastrous. Phil Venables did a great job in a recent post on budgeting to approach it as a supply and demand problem. 

The issue we end up having as Security leaders is that Security programs tend to be multi-dimensional, while it appears unidimensional to those outside of the field. The unidimensional view is backed by the typical platitude of measuring the Security budget as a percentage of the IT budget, rather than as a proportion of spending across a number of different budget areas. It’s time to dig in to understand how to get the appropriate Security funding, and stop answering the percentage of IT budget questions.

It is important at this point to discuss different types of spending that a business will account for. For the sake of this exercise, we will look at a typical SaaS business budgeting process, but this thinking can be applied to any business and the means of funding Security:

• R&D: The R&D Budget is allocated for the creation of products and services. This is the budget where the developers, product managers, and QA teams tend to live, and the technology that supports them. The R&D budget, in many cases in the United States, can also be capitalized and part of tax write offs for the business as part of doing research for new products. R&D costs exist up front in a product’s existence as part of building products, as well as fixing issues on an ongoing basis. When we say “shift left” it means that we are more and more in the R&D space.

• Cost-of-Goods-Sold (COGS): The COGS budget is what is needed in order to operate the product during its running life. In the SaaS example, this includes things like cloud hosting costs or datacenter operations costs, manpower around those environments, and other expenses related to delivery. COGS is used to calculate ongoing operating costs that impact product margins and profitability.

• Customer Acquisition Costs (CAC): The CAC budget is what it costs to find and onboard customers. The CAC budget typically includes sales and marketing expenses and the process of selling to a customer.

• General and Administrative (G&A): G&A budget is the overhead to run a business, and overhead is something that needs to be tightly controlled as it does not generate revenue. Teams typically covered under G&A include Information Technology (IT), Legal, Finance, Human Resources, etc.

There are other budget areas as well, but these four budget areas are the most important for this discussion with the SaaS example. Manufacturing will have other budget areas as will industries like health care, but we will start here.

As you read through these different areas, you can immediately start to see that Security teams actually touch a variety of these areas. It may become obvious that describing the entirety of the Security budget as a percentage of IT does not make sense. Moreover, if the entire budget is allocated to G&A, then Security will always be overhead, and it will become a perennial candidate for cutting costs.

Aligning Security to Budget Areas

One of the most important things a CISO can do is to start aligning different elements of the Security budget to the correct budget type. Once they are properly aligned we can then address scaling predictably to ensure ongoing proportional funding is provided to Security.

A typical Security organization for a SaaS company will consist of the following broad strokes groups:

• Product Security: Securing the product development and software development process, and the security of the products throughout their existence. This can include everything from threat modeling to product security incident response.
• Platform Security: Securing where things run whether they are in the cloud or on premise environments related to the products and services.
• Governance, Risk, and Compliance (GRC): Design and management of the organization’s governance controls and certifications required to operate, and managing risk on an ongoing basis.
• Enterprise Security: Securing where and how employees and contractors do their work for the organization. This can include securing endpoints, SaaS services used by the organization, identity, etc.

Each of the areas above have a strong linkage to the different budget areas enumerated earlier. We now need to define scaling factors for the Security budget that are foundational to ongoing budget discussions. Agreement on the scaling factors allows for the more strategic risk conversations to happen. The scaling factors should take into account headcount, consulting, software, and licensing costs germane to the area in question.

• Product Security -> R&D Budget: The Product Security team should be closely aligned to the investment and staffing levels of the R&D budget. One metric could be to determine a percentage of spend from R&D that should be applied to the Product Security team. Another is to scale headcount proportionately with a pre-defined ratio – e.g. 100:1 Developers-to-ProdSec (NB: this ratio is not a recommendation but an example). By agreeing on a ratio, the discussion isn’t the dollar amount of the Product Security budget, but more strategically about whether the ratio is correct for the organization. While the ratio can be used to scale up when the team grows, it can also be used to scale the team down when the number of engineers decreases. The ratio itself serves as a proxy for product complexity and velocity for which the Product Security team needs to account and stay ahead of. Also feel free to tell your CFO that those resources can now be capitalized just like the development teams.

• Platform Security -> COGS: Connecting the Platform Security team to COGS measures will help the Platform Security team with the growing complexity of an environment. Examples of scaling factors could be the number of cloud providers, number of regions, percentage of cloud or datacenter spend, etc. The key is to select a scaling factor that is representative of the size, velocity, and complexity of the environment and technologies being secured to properly fund staffing and tooling.

• GRC -> CAC: Part of the GRC program can be tied to the CAC stream. For example, obtaining compliance certifications/attestations (e.g. SOC2, ISO 27001, FedRAMP, etc) should be considered to be part of CAC since they allow the business to target certain desired customers. Likewise, if those customers are no longer desirable then that would allow for scrapping certifications. Establishing a customer trust portal could be another example as it is a branding/marketing exercise, but also a means of decreasing the sales cycle duration.

• Enterprise Security -> G&A: And now, the only part of the security budget which should be considered to be a percentage of IT spend. Securing the enterprise is directly linked, oftentimes, to the rest of the G&A costs and scales. If more employees are hired, or more SaaS products are procured, then it is reasonable to expect that the Enterprise Security costs will rise as complexity increases.

As you can see, there are ways of scaling the Security organizations in alignment with the business. By establishing the scaling factors, we can agree on the appropriate level of investment, and the board-level conversations are not around “do you have enough money?” but rather “have we altered our alignment and scaling factors?”. Also, an important note, the board does not allocate funds, but discussing scaling factors and risk/governance can be part of their oversight.

The other interesting byproduct is when a business undertakes M&A activities, it allows the corporate development team to quickly understand how much hiring will be needed for the Security team to properly align to the new resources or complexity being acquired.

Next Steps:

Meet with your Financial Planning and Analysis (FP&A) team, or your CFO, to understand how the budget is designed for the rest of the organization. If the Security budget is all G&A, then find ways to align parts of the program to the rest of the budgets. Then work with your CFO or FP&A to properly allocate the costs to those budget areas. You will be helping your finance team also achieve some of their own metrics by controlling G&A costs, which can look to be out of control if the entirety of the Security budget is under G&A.

Every leadership role is complex and involves strategy, influence, responsibility, and accountability in different forms. What make’s the CISO’s role different is that he or she has to understand how every part of the business performs its function in order to partner more effectively, and be the “business enablers” that we all strive to be. The need for CISO’s to be so cross-functional is very similar to how a Liberal Arts education explores alternate avenues outside of a given area of expertise to ask interesting questions. I still remember my amazement when my homework assignments for my Linguistics class were the same assignments for my Computer Algorithms class, but from different books. The interdisciplinary nature of the CISO’s role and continuous learning is what I find so compelling.

Executives should be leveraging the CISO’s unique perspective and exposure to the organization to help drive the business to new heights.

Most executives and their teams will focus on their area of expertise and apply it across the business to ensure optimal operations of the organization. The Finance team will work across the business managing treasury risk, operating costs, investments, and P&Ls which are all core to financial performance. The Human Resources team will work across the business on hiring, performance reviews, compensation, training, PIPs, etc, which are all core Human Resources functions.

Security teams must work with HR teams on insider risk, travel considerations, life safety, etc; CFO teams on financial risk, financial tools, SEC reporting, etc; CTO teams on development methodologies, product development, secure design, vulnerability management, etc; Legal teams on privacy controls, regulatory issues, incident management, etc; CIO teams on enterprise productivity tools, mobile devices, infrastructure, etc; Chief Revenue Officer teams on sales stages and pipelines, customer relations, collateral; and the list goes on and on. A CISO and his/her security team has to intimately understand how each of these teams does its work in order to measure risk, facilitate informed decision making by stakeholders, doing everything possible to secure the organizations, and prepare for resiliency and recovery. The breadth and depth of exposure that a CISO has to the business is part of what makes the role so challenging and interesting while also one of constant learning.

Taken another way, and this is to be explored in another post, CISOs need to understand every aspect of the business not only to help manage risk but also to understand how to align and enable the business. Enabling the business is not only about getting out of the business’ way or creating smooth paths, but it’s about helping the business to scale security in the right ways when needed depending on which part of the business needs scaling. It is also about helping to uncover ways of managing risk or perhaps reaching a higher plateau by exposing opportunities that may not have been perceived by the stakeholder.

Today, every citizen is on the front lines of the epidemic. We are flooded with information about staying safe, keeping an eye out, and left to process unfamiliar language.  We are all suddenly doctors and epidemiologists analyzing information and predicting how the world is changing. With countless health professionals, scientists, and officials publishing cautionary tales, it may sound like when your organization’s CISO tells you that Cybersecurity is everyone’s job, and perhaps throws some cyber-jargon at you.

Watching the initial response to COVID-19 has been a surreal experience not only because of how we have been iterating through the responses, but in its striking similarity to what Cybersecurity professionals see in their everyday lives. Cybersecurity’s overall goal is to help business understand risk so they can make informed decisions, and ensure the organization can detect, investigate, contain, and remediate issues rapidly. It’s easy to draw a parallel between a human virus and a computer virus, but the similarities are far more nuanced. 

Cybersecurity professionals work daily to understand organizational cyber risks and help leaders make risk-informed decisions. We present graphs and charts showing maturity level, identify Cybersecurity investment opportunities, and install tools anywhere we can. When all else fails, some ultimately and regrettably resort to leveraging Fear, Uncertainty, and Doubt (FUD).  Whatever the communication mechanism, many organizations view Cybersecurity as a “nice-to-have”, a necessary response to compliance, and often viewing their CISO as “Chicken Little”.

Cybersecurity’s lot sounds familiar to the pandemic planning’s predicament over the last few years. 

First, the National Security Council had a pandemic playbook available to them, much in the same way that an organization’s CISO has a Business Continuity Plan (BCP). However, when it came time, the plan was not put to use in favor of finding a custom approach to the problem. Organizations often have regulatory or customer obligations to have a BCP in place but it is often relegated to a shelf where it is brushed off for a cursory annual test. Our experience here is similar in that testing of the pandemic plan was not real enough to result in an automatic use of the plan.

Second, the pandemic unit was removed from the National Security council likely because a pandemic was not seen as an imminent threat to the nation. The corollary to Cybersecurity is striking because many organizations don’t have the CISO as part of the leadership team or present for strategic executive and board discussions. Sometimes the CISO is elevated to this level of visibility during a time of crisis, but memories are short and organizations often revert back in the absence of a clear immediate threat. The value the pandemic unit and the CISO bring to the larger group is not just expertise in their area but a different perspective to larger issues. Their perspectives and contributions outside of a time of crisis should not be discounted.

You Can’t Measure or Respond to Something You Can’t See

Rapid response to a crisis not only requires a well-practiced plan, but also the visibility to target the response. In the case of the United States response to COVID-19, we were caught flat-footed without the data needed to make strategic decisions. Instead, responders and officials were forced to use anecdotal evidence or data from small regionalized sample sets.  Assumptions had to be made about the illness’ prevalence, spread, impact, and mortality rate which have proven incorrect over time. Responding to the emergency without data-driven visibility has led to broadly implemented restrictions, overwhelmed health systems, and shortages of supplies.

The similarity of the response compared to Cybersecurity incidents becomes interesting when we think about visibility. The response to COVID-19 strongly mimics how organizations perform breach or ransomware response. Organizations that followed the direction of Cybersecurity leaders for instrumentation, centralized logging, and response exercises are like doctors who have had access to rapid testing. South Korea is the strongest corollary to a successful Cybersecurity program resulting from the amount of testing they performed early on, which enabled data-driven decisions focusing restrictions on affected citizens.

Instead, the United States Government’s response was the equivalent of a partially implemented Cybersecurity program. Sick patients are similar to users calling the helpdesk to report their computer is acting “weird”.  The only visibility the response team has is to examine reported ‘weirdness’ and systems on the network. The best we can do is respond to the reports we receive, investigate the systems in question, and remediate. The incident responders can perform additional investigations around the proximity of the affected system, but it is resource and time prohibitive to examine the entire enterprise. The only other option is to shut down the business until every system can be examined or rebuilt.

The decision on when to call the all-clear becomes even more challenging. When does the Cybersecurity team think that the threat has been contained?  If you don’t have visibility then you can take the stance that if no one is complaining then the problem must have been addressed, but it could just as easily recur elsewhere.  Much is the same with a country and figuring out how to strategically lift restrictions without ending up worse off. In short…Data is king.

Where Do We Go From Here?

Our collective experience from this pandemic is wasted if we don’t put lessons learned into forward planning more broadly. Going forward we should be prepared with information, data collection, and the ability to spot trends. It’s not to say that we can prevent all of the ills of the world, whether that’s physical, health, or cyber, but we can be better prepared to respond to minimize the impact.

Encourage your Cybersecurity organizations to acquire the data needed to make informed decisions, allow it and the business to act quickly, and preserve the organization.  Ask questions, rehearse in earnest, and make investments that provide insights. 

Benamin Franklin’s saying “if you fail to plan, you are planning to fail” could not ring truer.

TL;DR: CISOs are part of an organization to build out a risk management program to help measure and treat risk, whether technical, human, or otherwise. The CISO, as a member of the leadership team, then has to help the business understand the risks to make an informed decision about how to proceed. The part of the organization responsible for the risk area is then responsible for selecting the risk treatment. A CISO has failed if they have not properly measured risk and informed stakeholders of them.