Why This CISO Stopped Buying Security Tools and Builds Them Instead

Watch on: Spotify, Apple, YouTube

Most security leaders come up through IT or risk. Chris Bollerud came up through code.

Chris is the CISO at AppZen, an AI-driven finance platform that automates expense and invoice auditing. Before he ran security, he spent more than two decades as a software engineer, including a stint as a Master Engineer at HP. He was originally hired at AppZen to lead the engineering function and took on the CISO role as the company scaled.

That engineering background shapes how he sees almost every problem in this conversation. When he looks at a vendor, he can usually picture how to build the product himself. When he looks at a vulnerability, he thinks about where in the development process it should have been caught. And when he looks at the broader AI moment, he sees the same pattern playing out on both sides of the fence at once.

How AI is changing both sides of the security equation

Chris does not split AI into hype and reality the way a lot of people do. His take is simpler: AI is going to make everyone move faster, attackers and defenders alike, and the question is who adapts to that speed first.

On the attack side, the math has shifted. There are going to be far more zero days than there ever were before. Vulnerabilities that companies used to label low priority and ignore are now genuinely dangerous, because a model can scan for them, build a repeatable pattern or template, and hand it to an unsophisticated attacker who could not have found it on their own.

On the defense side, the same capability cuts the other way. A defender can point AI at their own code base, surface every instance of a known weakness quickly, and get proposed fixes back. And the fix does not always have to be a direct patch. Sometimes it is a workaround, a configuration change, or a firewall setting that blocks access to the vulnerable path. Chris frames this as defense in layers: the more layers you can put in place and actually know about, the better positioned you are.

Why shift left needs to become automatic, not aspirational

Everyone in security talks about shifting left. Chris is blunt about why it usually stalls: it puts work on developers and product owners, so it meets resistance, and you do not get it done in a single day. It is a work in progress that depends as much on relationships with the engineering team as it does on tooling.

The shift he is most excited about comes from how engineers are already changing their own habits. As teams move into agentic and vibe coding, developers are getting comfortable adding skills to their code base that interact with the models writing the code. That opens a cycle that did not exist before. You find a class of vulnerability once, then you update the skill so that vulnerability never gets introduced again, and you push that same guardrail into your CI/CD pipeline.

There is still a backlog of old vulnerabilities to clean up. But the point is to stop new ones from being created in the first place. Chris is direct about the stakes here. Code is being generated faster than ever, and if teams do not put the brakes on new vulnerabilities, they will not see a small increase, they will see something closer to a hundred times the volume. Getting ahead of that curve is the whole game.

He also wants shift left to mean more than training developers. Yes, developers need to understand secure patterns. But the real leverage is in the environment around them: skills embedded in the code base, integrations with the IDE that put a red squiggle under insecure code as it is written, higher quality scanning that can stop a risky pull request in the build process. The goal is to automate the catch, not rely on people to remember.

The pen test dinner that reframed application security

The cleanest illustration of Chris's philosophy came from a story about two vendor conversations on back-to-back days.

AppZen was running proof-of-concept evaluations with several AI pen test tools. At dinner one night, the CEO of one of those companies was thrilled that his tool had found a particularly hard to detect vulnerability that competing tools had missed. It was a real technical achievement.

The next day, Chris spoke with another vendor in the same evaluation. She mentioned that her tool had found the exact same vulnerability. The difference was what came next. She had it patched before it ever reached production.

That contrast is the entire argument for shifting left. Finding a hard vulnerability in a pre-release or production environment and fixing it at the last minute is no longer good enough. The mindset has to change toward catching and fixing issues as the code is written, with the developer, before the flaw is ever available to be exploited.

Building security tests the way engineers build product tests

When Chris reflects on what he wishes he had emphasized more as an engineer, the answer is test-driven development. The familiar cycle is write a failing test, write the code that makes it pass, then refine.

His insight is that those tests do not have to be limited to functionality and product requirements. You can write tests for security too. Certain coding mistakes show up over and over, which is a big part of why the OWASP Top 10 exists. Issues like SQL injection and cross-site scripting are well understood, but they are not trivial to defend against, and anyone coding very fast is likely to write several of them straight into a product.

The fix is the same pattern as everything else Chris describes. Put a skill in place that forces attention during code generation, so the model does not take raw user input and drop it straight into a database query. Instead it separates the parameters, validates and cleanses the input, and closes off the path an attacker would use to reach the database.

Where AI governance frameworks fall short

For vendors and AI-native companies, the most immediate AI security problem is not at the code layer. It is in the sales cycle.

Chris argues the entire third party risk management process is due for an adjustment. For years, companies had their questionnaires and their answers settled into something consistent. Then AI arrived fast, and a wave of companies stood up AI councils, each developing its own way of asking questions and each driving different concerns. The result is a patchwork with very little shared ground.

He would like to see a standards body create something that lets a company eliminate the bulk of those repetitive questions by meeting a recognized bar. The candidates exist on paper, including ISO 42001 and the NIST AI Risk Management Framework. The problem is trust. Chris has not seen his customer base treat those frameworks as sufficient. Even when a vendor holds the certification, the customer still sends the hundred, two hundred, or three hundred questions, and then asks for a meeting on top of that.

His read on why is specific and worth sitting with. In his view, the frameworks are not written from a security perspective to the depth these companies need in order to trust them. Something like ISO 42001 is largely about having a consistent process in place. It touches on security, but not deeply enough to let a buyer check the box and move on.

Why "where is my data going" is the question every buyer asks

Strip the questionnaires down and one concern sits underneath most of them. Where does my data go.

When you type a prompt into a model, where does that prompt travel, and how is the data used. An enterprise contract offers protection, but Chris is candid that a legal contract is all it is. It is not a technical guarantee of where data lives. So buyers keep asking the layered version of the same question: where is the model running, what data is allowed into it, how is that data protected, and what happens to the responses.

He draws a sharp line between two kinds of AI here. With predictive AI, the team building the model controls and curates the training data. With an LLM or foundational model, you are pulling in someone else's model, often hosted somewhere else entirely, which opens a new set of questions about data handling that older governance frameworks were never built to address. As Chris puts it, the frameworks tend to cover the governance process while skipping the harder questions about training sets, curation, and how customer data interacts with the model.

The one review that changed how Chris communicates

The most personal moment in the conversation had nothing to do with AI on the surface, and everything to do with it underneath.

Early in his career at HP, Chris got a review that stung for a long time. Overall it was positive, as his reviews generally were. But one sentence stayed with him for years: Chris does not understand the impact of his words.

It took him a while to absorb it, and once he did, it reshaped how he thinks about communication. What you say and how you interact with people carries weight, and the job is to make sure your message is truthful and lands the way you intend.

He connects that lesson straight to the AI era. His worry is trust. He believes there is more bad information online now than good, and that telling real from fake will be one of the defining problems for the next generation. Old propaganda was a person trying to influence you in the wrong direction. AI slop is harder, because you cannot easily tell what is real. If people do not develop the skill to identify trusted sources, someone will build a new propaganda engine that moves society in a direction it never chose. The way out, in his framing, runs through liberal arts, time spent away from screens, and travel that reminds you the rest of the world does not operate the way Silicon Valley does.

Security is a people problem before it is a technical one

Chris and Taylor discuss a thread on Reddit asking what the hardest part of cybersecurity is. Across hundreds of responses, the overwhelming majority were about people, not technology. His own experience matches that.

His core principle is to build relationships before you need them. Security teams are small, and when something goes wrong, Chris needs the rest of the company to act as if they work for him, even though no one on that list reports to him and he is not writing their reviews. The only way that cooperation exists in a crisis is if the relationship was built long before the crisis arrived.

So he spends time across the org, with sales, legal, IT, support, managers, and the people doing the day to day work. Legal has been an especially important partnership, because security and legal face customers together. He has invested heavily in getting the legal team aligned on the process and the shared FAQ, to the point where they can answer most customer questions on the spot without pulling him in, and the deal keeps moving.

The CISO community plays the same role at the peer level. Chris is meeting another CISO almost every week, and those relationships form fast because the experience is shared. Different companies are working through the same pains and the same wins, and they trade lessons and moral support across the group.

He also names the reputation he is constantly working against: that CISOs say no to everything. His reframe is that he is not there to say no. He is there to make sure that when the answer is yes, it happens in a way that is secure and compliant across California, European, and federal law. The line he repeats is that he is there to help the company move fast, but down the right path.

What makes a real moat in an AI-first market

Chris closes with advice aimed at founders and investors, and it lands harder coming from an engineer who buys security tools for a living.

There are a lot of startups right now, and many of them are not building a real moat or a real business model. You cannot launch a product the way you could ten or fifteen years ago and expect companies to pay a lot for it. Chris is living proof of the shift. AppZen has stopped purchasing most vendors and instead builds tools in house. When a buyer can vibe code roughly eighty percent of your product in a couple of weeks, even with a worse UI, they are not going to pay fifty or a hundred thousand dollars for the polished version.

So the question every founder has to answer is what value they bring that the customer cannot easily build themselves. Chris is specific about what counts as a moat. The recent purchases he has made came down to two things: the tool was cheaper than building and maintaining an equivalent, or it solved a problem that would cost him too much time to replicate. The strongest example he gives is integrations. Building a product once is one thing. Maintaining a thousand integrations that all have to work together and that change constantly is genuinely hard, and a product that makes that maintenance burden disappear has a real moat.

He names two other candidates, hardware and holding your own data, while flagging that he avoids products designed to hold a customer hostage to their data. And he is honest about the flip side of his own skill set. As a software engineer, he can see how most of these products work and how to replace them. An AI pen test tool, a scanning tool, even some SOC agents that parse large volumes of text are not that difficult to stand up anymore, because anytime the core task is interacting with a lot of text, an LLM can do a lot of the work.

For everyone across the ecosystem, that is the signal worth holding onto. The pace of AI is compressing the distance between an idea and a working product, on the attack side, the defense side, and the vendor side all at once. The teams that win are the ones building durable value and durable trust faster than that distance closes.

Frequently asked questions

What does it mean to shift left in security? Shifting left means catching and fixing security issues earlier in the development process, ideally as code is written, rather than running a pen test against a pre-release or production environment and patching at the last minute. Chris Bollerud argues it should be automated through skills in the code base, IDE integrations that flag insecure code, and scanning in the build pipeline, rather than relying on developer training alone.

Why don't AI governance frameworks like ISO 42001 and NIST AI RMF satisfy enterprise buyers? According to Chris Bollerud, buyers still send hundreds of security questions even when a vendor holds these certifications because they do not yet trust the frameworks. His view is that the frameworks focus on having a consistent governance process but are not written from a deep enough security perspective to let a buyer check the box and move on, especially around training data, curation, and how customer data interacts with foundational models.

What is the OWASP Top 10 and why does it matter for AI-generated code? The OWASP Top 10 is a regularly updated list of the most common and dangerous web application security risks, including SQL injection and cross-site scripting. These flaws are well known but not trivial to defend against, so code generated very quickly is likely to include several of them. Putting security-focused skills and tests in place helps stop those patterns from being written into the code base.

Why is "where is my data going" the central question in AI security? Most third party risk questions reduce to data handling. Buyers want to know where a model runs, what data is allowed into it, how that data is protected, and what happens to the responses. An enterprise contract offers legal protection but not a technical guarantee, and pulling in a foundational model hosted elsewhere opens data handling questions that older frameworks were not built to answer.

What makes a real moat for a security startup in the AI era? Chris Bollerud says many AI startups lack a durable moat or business model. With buyers able to vibe code a large share of a product in weeks, founders have to offer value the customer cannot easily build, such as a large set of constantly changing integrations that are hard to maintain, hardware, or controlling their own data. Tools that earn the purchase tend to be cheaper than building in house or solve a problem that would cost too much time to replicate.

-

The Cybersecurity Ecosystem Show connects practitioners, investors, vendors, regulators, and everyone in between. New episodes drop weekly. Subscribe so you don't miss one.