I’ve been spending a lot of time lately building Systematic Reasoning with my long-time friend Vishal. The core premise is straightforward. Organizations reveal their true operational character through how they design to prevent failure, how they plan to handle it when it happens, and how they actually do. That signal deserves to be tracked, structured, and acted on. We’re building an agentic compliance platform to do exactly that.
Systematic Reasoning won’t be limited to any single domain, but we decided to start with the Web PKI. The reasoning was simple. It’s high impact in a way that’s hard to overstate. Every internet user depends, whether they know it or not, on a relatively small number of Certificate Authorities getting things right. The margin for error is zero. If that trust layer breaks, it breaks for everyone.
DigiNotar is the canonical example. A small Dutch CA, compromised so thoroughly that attackers could impersonate any website on the web, and did. That capability was used to spy on Iranian dissidents, intercepting communications that people believed were private and secure. The trust infrastructure that was supposed to protect them was turned into a weapon against them. DigiNotar isn’t an edge case or a cautionary tale from a more naive era; it’s a demonstration of the actual ceiling of what can go wrong. And it isn’t the only one. State-affiliated certificate authorities have been caught performing man-in-the-middle attacks on their own citizens’ traffic, something the Baseline Requirements explicitly prohibit, but prohibition only matters if it’s enforced. The web’s trust model works right up until the moment someone decides it’s more useful as surveillance infrastructure.
At the core of Systematic Reasoning, is a belief I’ve held for a while. Compliance can be a vital sign of organizational security, but only if it’s continuous. The reality today is that it isn’t. Code ships daily. Audits happen annually. The gap between those two rhythms is where things go quietly wrong.
I’ve written before about why I have limited faith in the current audit regime. Auditors are engaged by the organizations they assess. Their product is a clean seal; their incentive is to keep the client. They operate on point-in-time sampling with auditee-selected scope, and they’re often compliance professionals rather than engineers, which means they’re checking whether a policy exists more than whether the system actually behaves correctly. That’s if you’re lucky. Sometimes the audit is scoped against a version of the Baseline Requirements that was superseded over a year ago.
The same incentive shapes how certificate authorities write their governance documents. A CP/CPS that relies heavily on incorporation by reference, that omits specifics about what the organization actually does and what constraints it operates under, is easier to audit against than one that makes precise, testable commitments. Vagueness isn’t always carelessness. Sometimes it’s a design choice. The same thing happens in incident reports. A report that attributes a failure to “organic process evolution” or “human error” without describing the actual control gap is easier to close than one that names the broken system and commits to a specific fix. In both cases the document gets the box checked without creating accountability. References establish authority. Commitments establish accountability.
The audit gap isn’t compensated for by strong internal monitoring either. The majority of significant compliance failures are not caught internally. They are caught by external researchers, root program staff, or community tooling. A broken validation endpoint runs for five years and the organization finds out because someone posted a 404 error in a public issue tracker. A validation race condition exists undetected for seven and a half years not because it was well hidden but because nobody was looking. The absence of an internal alarm is not evidence that the system is healthy. It is often evidence that the monitoring itself is missing.
So public incident reports and governance documents become some of the most signal-rich material available. Policy documents tell you what an organization claims it will do. Incident reports tell you what happened when reality diverged from that claim. Together they create a longitudinal picture that neither document produces alone.
Building a system to reason over that data surfaced a problem I didn’t fully anticipate. When you’re working from the outside, with no access to internal systems and no way to verify what actually changed, the public record is almost all you have. The question isn’t whether to treat it with skepticism. It’s how much skepticism to build in by default.
The temptation is to give the benefit of the doubt. Organizations are required to describe the blast radius of an incident. Not every localized bug is a symptom of something systemic. But accepting minimizing language at face value is its own failure.
“Only” is doing a lot of work when the bug it’s describing went undetected for seven and a half years. “No compromise of end-entities” is doing a lot of work when what it really means is that nobody found the gap before you did. Framing survival as security isn’t reporting, it’s PR. And if an organization believes an incident is no big deal, you can predict with reasonable confidence that the root cause analysis will be shallow and the remediation will be a band-aid.
ForgeIQX, our first offering, tracks those signals longitudinally across both policy documents and incident reports. Not to prosecute organizations for their language choices, but to notice when a commitment made in a CP/CPS quietly disappears in the next version, or when a promised fix is nowhere to be found when the same failure mode surfaces years later. That’s commitment decay, the slow evaporation of a promise made under pressure, and it’s only visible if you’re tracking across multiple documents and incidents over time rather than treating each one in isolation.
The calibration problem is real and doesn’t have a clean answer. Get it wrong in one direction and you build a system that cries wolf. Get it wrong in the other and you build a system that launders PR-speak into clean signals, which is just automating the thing we already do too much of.
There’s a third failure mode that took me longer to see. A system like this can be gamed. Swap “we got lucky” for “our monitoring detected no active exploitation.” Replace “only thirty certificates” with a more clinical impact scoping statement that says the same thing in language that sounds like engineering rigor. The words change; the institutional posture doesn’t. A system that can be satisfied by better prose isn’t measuring operational maturity, it’s measuring communications sophistication.
That means the system has to be built with structural pessimism. Not cynicism for its own sake, but a deliberate prior that clean language is not the same as clean operations, and that the absence of red flags is not the same as the presence of green ones. We can’t verify that an organization fixed what it said it would fix. What we can do is watch whether the same failure mode surfaces again and whether the pattern of shallow root cause analyses continues or breaks. The historical record doesn’t tell us what’s true inside these organizations. It tells us what they were willing to say in public, under pressure, over time. Given the alternatives, that may be the most honest signal available.
A certificate authority with genuine operational maturity should want this kind of scrutiny applied to itself. Not because it will always produce a clean result, but because it surfaces the gaps before an external party does. ForgeIQX gives organizations a way to continuously monitor their own compliance posture, so their practices and code keep pace with their commitments. The same is true for auditors who want their findings to mean something beyond a checkbox. The problem with the current regime isn’t that the people in it are careless. It’s that the incentive structures don’t reward rigor, and the tooling to demonstrate it continuously doesn’t exist. That’s what we’re building.
The Web PKI is where we started because the stakes are concrete and the public record is unusually rich. But any regulated industry where compliance is measured annually, where governance documents are written to satisfy auditors rather than inform relying parties, and where incident reports are drafted with one eye on legal exposure, has the same gap between what the paper says and what the organization actually does. We started here. We don’t intend to stop here.
“Distribution is the new moat.” You can find some version of that sentence in almost any startup discussion from the last year. It circulates as a take, gets liked, gets reshared, and then gets reproduced by someone else who arrived at the same conclusion independently. The observation has become cheap to make precisely because it is true. What is harder, and what most of those takes skip, is understanding why the structural mechanics behind it matter and what they actually require you to do differently.
For decades, venture capital rewarded the ability to build. In the AI era, building is no longer scarce. Distribution is.
There was a time when building complex software required deep teams, long timelines, and substantial capital. Engineering was the constraint. Infrastructure was the constraint. Expertise was the constraint. That constraint justified venture scale returns.
AI is dissolving that constraint, not all at once, and not uniformly across every domain, but steadily and in ways that are already measurable.
This is not a cliff. It is a slope.
The companies founded today still face real execution challenges. The ones founded three years from now will face fewer. The ones founded ten years from now will operate in an environment where the cost of building sophisticated systems is a fraction of what it is today. We are in the early middle of this shift, not at the end of it. That matters because the temptation is to look at current valuations, current outcomes, and current M&A multiples and conclude that nothing has changed. Something has changed. It is just moving at the pace of markets and human institutions, not at the pace of model releases.
The Repricing of Expertise
We are watching a repricing of expertise, a slow one, with uneven edges.
Not at the foundational layer. Paradigm-shifting breakthroughs still matter. The rare intellectual leap that unlocks a new architecture or a new computational primitive remains valuable and durable. But most companies are not those breakthroughs. Most companies sit on top of them.
I have written before about how AI is repricing skill at the individual level, injecting liquidity into what was once a slow-moving market for technical expertise. What is happening at the venture level is the same dynamic playing out across entire product categories. When fifty startups can build near-equivalent products in twelve months, product differentiation compresses. Expertise becomes assisted. Execution becomes accelerated. Barriers to entry fall.
It is worth being direct about what that means. AI does not just flatten products. It flattens people. The scarcity that once justified premium human expertise, the advisor with the rare insight, the consultant who had seen this problem before, is narrowing. That edge does not disappear, but it compresses fast unless the expertise is embedded in distribution, in relationships and customer context that cannot be replicated from a prompt.
There is an important exception. In data-rich verticals, proprietary datasets create compounding advantages that AI amplifies rather than erodes. Healthcare, finance, legal, infrastructure – in these markets the data is not just an asset, it is a moat that gets stronger as it grows. AI makes that data more useful, not less defensible. The dynamic in these verticals is different. The scarcity is not building capability or even distribution in the generic sense. It is the data itself, and the domain-specific judgment required to use it correctly. This connects to a broader point worth sitting with: when you rent the capability layer, you rent the moat. In AI-native verticals, whoever owns the model behavior owns the product – and that is a different kind of lock-in than anything cloud computing created.
The result is predictable. A wave of companies will launch in every attractive AI-adjacent category. Many will grow quickly. Many will look venture-scale in their first 24 to 36 months. Most will not become venture-scale businesses.
They will explode and then flatten.
Not because they were poorly run. Not because the founders lacked talent. But because it became too inexpensive to create what they created. The winner-take-most dynamic compresses margins and growth for everyone except the few that secure durable control.
Cheap building creates crowded categories. Crowded categories destroy the middle of the return distribution.
The venture math here deserves to be stated plainly. Cheap building means more competitors. More competitors cap market power. Capped market power caps exit multiples. In a crowded AI category where any competent team can replicate the core product, the venture model itself compresses. Not because the market is small, but because structural dominance becomes harder to achieve and sustain. Many of these companies are structurally unlikely to become venture-scale businesses. The category economics will not support multiple large players once replication costs collapse, and most founders do not have the distribution infrastructure to be the one that survives. Asymmetric outcomes remain possible. They are just harder to achieve and harder to sustain in categories where the product itself can be reproduced quickly.
What This Does to Venture Capital
This has structural consequences for venture capital, though they will play out over years, not quarters.
If building is cheap and competition is abundant, returns concentrate harder and faster. You get more rockets. Fewer reach orbit.
Investors will demand signal sooner. Growth becomes the proxy for distribution dominance. Capital is deployed to test whether the company can win quickly, not whether it can build elegantly. The tolerance for long, patient build cycles without distribution proof shrinks. Capital releases in stages tied to evidence of emerging control.
This is reshaping round structure too. When building is cheap, large upfront rounds are harder to justify – you no longer need $20M to construct the product. Seed rounds compress because the build cost does not warrant more. But growth rounds are becoming larger and more heavily tranched, with capital tied to distribution milestones rather than product ones. Channel proof. Embedded customer cohorts. Pipeline velocity. The structure of the round starts to reflect the new scarcity. Capital flows in proportion to what is actually hard, and what is actually hard is no longer building the thing.
The traditional power-law model assumed a long tail of moderate outcomes. In a world of rapid replication, the moderate outcome becomes harder to sustain.
Meanwhile, IPO pathways have narrowed. The regulatory intent was investor protection. The outcome was exclusion. By making it harder for companies to go public early, regulators locked retail investors out of the steepest part of the value curve, the years when a company moves from promising to dominant. Secondary markets expanded to fill the gap, but access to those markets is not democratic. Private capital captures what public markets used to offer to a broader population. Venture starts to look less like broad-based growth capital and more like concentrated private allocation, closer to family offices, less like 1990s expansion funds. AI will likely accelerate that dynamic. The companies creating the most value will stay private longer, and the people with access to them will be a narrower group than before.
Selectivity increases. Portfolio sizes shrink or become more strategically concentrated. The “grow at all costs, you’ll get more later” model becomes harder to justify when many fast-growing companies are structurally incapable of sustaining dominance. Capital no longer buys uniqueness. It buys speed – the time and resources to build a distribution funnel, execute against it, and reach durable entrenchment before a competitor replicates the product and races to the same buyers.
Built for Acquisition, But It Is Not a Spreadsheet Decision
There is another dynamic that becomes more visible in this environment. Some startups are designed not to become category winners, but to slot perfectly into one specific incumbent. Not strategic fit in the abstract sense. Deliberate adjacency to a single buyer. The product is built to complete a portfolio gap. The roadmap mirrors a specific weakness in a specific acquirer’s product line. Some founders are not optimizing for market dominance. They are optimizing for perfect adjacency to one buyer, and shaping every decision around what makes that buyer say yes.
This is not new. But the calculus around it is shifting.
When technology is easier to replicate, the premium for strategic fit increases relative to the premium for raw IP. At the same time, the value of acquiring technology alone diminishes. If a product can be rebuilt internally in 12 to 18 months, the acquisition multiple compresses. The technology becomes a starting point for an internal conversation, not a reason to write a check.
What remains valuable in M&A is harder to replicate. Embedded distribution. Contractual entrenchment. Regulatory positioning. Customer relationships. Data gravity.
In regulated verticals, this goes further. A company that has already navigated the compliance requirements to operate in a market – secured the certifications, built the audit trails, established the regulatory relationships – has compressed years of a buyer’s time to market into something acquirable. Compliance readiness is not a cost center. It is a distribution accelerator. Vertical access and compliance readiness are part of the distribution story, not separate from it. For an acquirer trying to enter a regulated market, the fastest path is often not to build the product. It is to buy the company that already has permission to operate. That shifts what gets priced into an acquisition and why some targets command premiums that pure technology analysis cannot explain.
Technology without distribution is just an expensive prototype.
But what gets lost in that clean analysis is that acquisition decisions are not made by spreadsheets. They are made by people, in rooms, often under time pressure, with incomplete information and competing organizational interests.
A founder who has built real relationships inside a strategic buyer has a fundamentally different acquisition outcome than one who has not, even if the products are comparable. The internal champion who has watched you execute, who trusts your judgment, who has gone to bat for you in internal budget conversations, is not a nice-to-have. They are often the reason a deal happens at all.
Perception compounds this. Acquirers pay for confidence as much as capability. A company perceived as the category leader, even in a crowded category, commands a premium that may not be fully justified by its metrics. Market positioning, analyst coverage, conference presence, and the quality of your reference customers, these shape the narrative in an acquirer’s boardroom. The story they can tell internally about why they did this deal matters enormously. Acquisitions have to survive internal politics.
Timing is almost never purely rational either. Companies get acquired when a buyer is scared, or ambitious, or has capital to deploy, or is about to lose a competitive advantage they can feel slipping. Being visible and credible at that moment, not just when you need a buyer, is what closes deals.
None of this means product and metrics do not matter. They do. But they matter as the floor. Above the floor, acquisition outcomes are determined by relationships, reputation, and the story someone is willing to tell on your behalf inside an organization that does not know you.
The Irony of Automating Your Own Moat
Customer management is one of the domains AI is aggressively trying to automate. AI SDRs. AI account managers. Synthetic personalization. Automated follow-up. Generated relationship intelligence.
In a world where distribution is the scarce resource and relationships drive acquisition outcomes, the industry is racing to replace human relationship infrastructure with synthetic substitutes.
This is not irrational. Automation increases efficiency. Most sales and account management processes have enormous amounts of low-value activity that could and should be automated.
But in high-value markets, buyers are not just purchasing functionality. They are purchasing risk reduction. They are purchasing accountability. They are purchasing confidence. And confidence is built through consistent human judgment over time, through the accumulation of trust that comes from someone showing up, delivering, and being present when things go wrong.
There is a related dynamic at the talent level. I have written about how AI is eliminating the on-ramp for early-career engineers, absorbing the low-context work that once let junior developers accumulate the judgment and institutional knowledge that makes senior engineers valuable. The same problem applies to the people who build enterprise relationships. The craft of reading a room, navigating a stalled deal, and managing a difficult renewal, these compound over years of real exposure. Automating the entry-level work in sales and customer success is not just an efficiency play. It shapes who gets the chance to develop the judgment the role ultimately requires.
Assistive automation increases efficiency. Primary automation risks eroding the very thing that becomes the last defensible moat.
The counterargument is that AI can also accelerate distribution itself. Faster outreach. Better targeting. Smarter personalization at scale. That is true as far as it goes. But it confuses distribution tactics with distribution durability. AI can help you reach more people faster. It cannot manufacture the trust that makes them stay, the embeddedness that makes switching costly, or the relationship capital that makes an acquirer’s internal champion go to bat for you. Speed without stickiness is just faster noise.
In a world saturated with synthetic output, authentic relationships are appreciated. The companies that understand this distinction, between automating the low-value repetitive work and preserving the high-value human judgment, will have a structural advantage over those that optimize purely for efficiency.
Forward-deployed engineers become strategic assets. Customer success becomes competitive infrastructure. Enterprise sales become durable leverage.
This will not be obvious in year one. It will be obvious in year five.
Overgrowth Risk
Cheap building combined with abundant capital creates another problem. When capital is deployed to chase an early signal, companies scale headcount and burn before structural dominance is secured. If they are not the winner in their category, they are left with a cost structure built for orbit and a trajectory that never left the atmosphere.
They grew too fast for a market that would not support multiple large players.
This risk increases when categories are crowded, and replication is easy. AI does not eliminate business fundamentals. It amplifies their consequences.
The Structural Shift
The AI era does not eliminate venture capital, entrepreneurship, or breakthrough innovation.
It shifts the locus of scarcity, gradually, unevenly, and irreversibly.
Foundational intellectual leaps remain rare and valuable. But most startups are not foundational leaps. When building was expensive, builders won. When building becomes cheap, distribution becomes destiny.
This transition is already underway. It is not complete. The companies founded in the next few years will discover its contours the hard way, either because they adapted early or because they did not.
The founders who understand what is happening will optimize differently. They will invest in buyer access before polishing perfection. They will treat relationships as infrastructure. They will see funnel design as a core product, not a marketing afterthought. They will build the internal champions inside their strategic targets before they need them.
And they will move fast on all of it. When building is cheap, the window to establish distribution before a competitor replicates the product is shorter than it has ever been. Timing has always mattered in startups. In this environment, it compounds differently – being six months earlier into a key account, a channel partnership, or a strategic relationship can be the difference between owning the category and being one of the many that flattened. Speed used to be about shipping. Now it is about embedding.
The VCs who understand it will underwrite differently. They have always asked whether the product is impressive and whether the founders are domain experts worth betting on. Those questions do not go away. But distribution used to be a problem you could punt on, something a strong team would figure out in year two or three. That tolerance is shrinking. Investors will put more weight on whether the company already has a credible path to controlling the channel, and be less willing to assume it will materialize later.
Because in a world where fifty companies can build the same thing, the only one that matters is the one that owns the channel and has convinced someone on the inside that betting on them was the right call.
Technology used to be the moat.
Now the moat is access. And access is built by people, over time, in ways that are harder to automate than we would like to admit.
I’ve been thinking about Conway’s Law, the idea that organizations “ship their org chart.” The seams are most visible in big tech. Google, for example, once offered nearly a dozen messaging apps instead of a single excellent one, with each team fighting for resources. The same pattern appears everywhere: companies struggle to solve problems that cross organizational boundaries because bureaucracy and incentives keep everyone guarding their turf. The issue is not the technology; it is human nature.
I caught up with an old friend recently. We met at nineteen while working for one of the first cybersecurity companies, and now, in our fifties, we both advise organizations of every size on innovation and problem-solving. We agreed that defining the technical fix is the easy part; the hard part is steering it through people and politics. When change shows up, most organizations behave like an immune system attacking a foreign antibody. As Laurence J. Peter wrote in 1969, “Bureaucracy defends the status quo long past the time when the quo has lost its status.”
Naturally, the conversation drifted to AI and how it will, or will not, transform the companies we work with. I explored this in two recent posts [1,2]. We have seen the same thing: not everyone is good at using AI. The CSOs and CTOs we speak with struggle to help their teams use the technology well, while a handful of outliers become dramatically more productive. The gap is not access or budget; it is skill. Today’s AI rewards people who can break problems down, spot patterns, and think in systems. Treat the model like a coworker and you gain leverage; treat it like a tool and you barely notice a difference.
That leverage is even clearer for solo founders. A single entrepreneur can now stretch farther without venture money and sometimes never need it. With AI acting as marketer, product manager, developer, and support rep, one person can build and run products that once demanded whole teams. This loops back to Conway’s Law: when you are the entire org chart, the product stays coherent because there are no turf battles. Once layers of management appear, the seams show, and people ship their structure. Peter’s Principle follows, people rise to their level of incompetence, and the bureaucracy that emerges defends that status.
Yet while AI empowers outliers and small players, it might also entrench new kinds of monopolies. Big tech, with vast data and compute resources, could still dominate by outscaling everyone else, even if their org charts are messy. The question becomes whether organizational dysfunction will outweigh resource advantages, or whether sheer scale still wins despite structural problems.
The traditional buffers that let incumbents slumber (high engineering costs, feature arms races, and heavy compliance overhead) are eroding. Payroll keeps rising and headcount is the biggest line item, while the newest startups need fewer people every quarter. I expect a new wave of private-equity-style moves: smaller players snapped up, broken into leaner parts, and retooled around AI so they no longer rely on large teams.
Social media voices such as Codie Sanchez highlight the largest generational transfer of wealth in history. Many family-owned firms will soon be sold because their heirs have no interest in running them. These so-called boring businesses may look ripe for optimization, because most still rely on human capital to keep the lights on. Just above that tier we see larger enterprises weighed down by armies of people who perform repetitive tasks. A modern consulting firm armed with AI could walk into any of these firms and automate vast swaths of monotonous work that keeps those businesses running. Incumbents will struggle to move that fast, trapped by the very structures we have been discussing. A private-equity buyer, on the other hand, can apply the playbook with no sentimental ties and few political constraints.
ATMs let banks cut tellers and close branches. Customers later missed human service, so smaller neighborhood offices came back. AI will force every sector to strike its own balance between efficiency and relationship.
They say history doesn’t rhyme but it repeats, if so incumbents who dismiss AI as hype may follow Blockbuster into the museum of missed opportunities. In Wall Street (1987), Michael Douglas plays Gordon Gekko, a corporate raider who uses leveraged buyouts to seize firms like Blue Star Airlines, an aircraft maintenance and charter company. Gekko’s playbook, acquire, strip assets, slash jobs, was ruthless but effective, exploiting inefficiencies in bloated structures. Today, AI plays a similar role, not through buyouts but by enabling leaner, faster competitors to gut inefficiencies. Solo founders and AI-driven startups can now outpace large teams, while private-equity buyers use AI to retool acquired firms, automating repetitive tasks and shrinking headcounts. Just as Gekko hollowed out firms in any industry, AI’s relentless optimization threatens any business clinging to outdated, bureaucratic org charts.
Across news, television, music, and film, incumbents once clung to their near-monopoly positions and assumed they had time to adapt. Their unwillingness to face how the world was changing, and their instinct to defend the status quo, led to the same result: they failed to evolve and disappeared when the market moved on.
TheAsk? incumbents, you need to automate before raiders do it for you.
Limitations often spark the most creative solutions in technology. Whether it’s budget constraints, legal hurdles, or hardware restrictions, these boundaries don’t just challenge innovation, they fuel it.
This principle first clicked for me as a broke kid who desperately wanted to play video games, but I did have access to BBSs, a computer, and boundless curiosity. These bulletin-board systems hosted chat rooms where people collaborated to crack games. To access premium games, you needed to contribute something valuable. This necessity sparked my journey into software cracking.
Without prior expertise, I cycled to the local library, borrowed a book on assembly language, and began methodically reverse-engineering my favorite game’s copy protection. After numerous failed attempts, I discovered the developers had intentionally damaged specific floppy-disk sectors with a fine needle during manufacturing. The software verified these damaged sectors at runtime, refusing to operate without detecting these deliberate defects. Through persistent experimentation and countless hours of “NOP-ing” suspicious assembly instructions, I eventually bypassed the DRM. This experience vividly demonstrated how necessity, persistence, and precise technical exploration drive powerful innovation.
This principle consistently emerges across technology: constraints aren’t merely obstacles, they’re catalysts for creative solutions. The stories that follow, spanning console gaming, handheld computing, national semiconductor strategy, and modern AI research, illustrate how limits of every kind spark breakthrough thinking.
Nintendo: Legal Ingenuity Through Simplicity
In the late 1980s, Nintendo faced rampant cartridge piracy. Rather than implementing complex technical protections that pirates could easily circumvent, Nintendo embedded a simple copyrighted logo into their cartridge ROMs. Games wouldn’t run unless the boot sequence found an exact match. This elegant approach leveraged copyright law, transforming minimal technical effort into robust legal protection.
Palm OS: Creativity Driven by Extreme Limitations
Early Palm devices offered just 128 KB to 1 MB of memory, forcing developers into remarkable efficiency. Every feature required thorough justification. As a result, Palm OS applications became celebrated for their simplicity, responsiveness, and intuitive user experience. Users valued these apps precisely because constraints compelled developers to distill functionality to its essential elements.
China’s Semiconductor Innovation Under Sanctions
When international sanctions limited China’s access to advanced semiconductor technology, progress accelerated rather than stalled. Chinese companies turned to multi-patterning, chiplet packaging, and resilient local supply chains. Constraints became catalysts for significant breakthroughs instead of barriers to progress.
DeepSeek: Innovating Around GPU Limitations
DeepSeek faced limited access to the latest GPUs required for training large AI models. Instead of being hindered, the team embraced resource-efficient methods such as optimized pre-training and meticulously curated datasets. These strategic approaches allowed them to compete effectively with rivals possessing far greater computational resources, proving once again that constraints fuel innovation more than they impede it.
Constraints as Catalysts for Innovation
Across these diverse stories, constraints clarify objectives and inspire resourcefulness. Limits narrow the scope of possibilities, compelling individuals and teams to identify their most critical goals. They block conventional solutions, forcing innovative thinking and creative problem-solving. Ultimately, constraints channel energy and resources into the most impactful paths forward.
Turn Limits into Tools
The next time you face constraints, embrace them, and if you need to spark fresh ideas, consider deliberately creating limitations. Time-box a project to one week, cap the budget at $1,000, or mandate that a prototype run on a single micro-instance. Necessity doesn’t just inspire invention; it creates the exact conditions where meaningful innovation thrives.
What constraint will you impose on your next project?
When selling security solutions to enterprises, understanding who makes purchasing decisions is critical to success. Too often, security vendors aim their messaging at the wrong audience or fail to recognize how budget authority flows in organizations. This post tries to break down the essential framework for understanding enterprise security buyer dynamics.
While this framework provides a general structure for enterprise security sales, industry-specific considerations require adaptation. Regulated industries like healthcare, finance, and government have unique compliance requirements, longer approval cycles, and additional stakeholders (e.g., legal, risk committees).
The Buyer Hierarchy
The first key concept to understand is the buyer hierarchy in enterprise security.
Figure 1: The Buyer Hierarchy
This pyramid structure represents who typically makes purchasing decisions at different price points:
At the base of the pyramid are Security and IT Managers. These individuals make most purchase decisions, particularly for:
Standard solutions with established budget lines
Renewals of existing products
Smaller ticket items
Solutions addressing immediate operational needs
Moving up the pyramid, we find Security and IT Directors who typically approve:
Larger deals requiring more significant investment
In security sales, it’s crucial to distinguish between two key players:
The Champion: This person is chartered to solve the problem. They’re typically your main point of contact and technical evaluator – often a security engineer, DevOps lead, or IT admin. They’ll advocate for your solution but rarely control the budget.
The Buyer: This is the person who owns the budget. Depending on the size of the deal, this could be a manager, director, or in some cases, the CISO. They make the final purchasing decision.
Understanding this dynamic is critical. Too many sales efforts fail because they convinced the champion but never engaged the actual buyer.
The Budget Factor
Another critical dimension is whether your solution is:
Pre-budgeted: Already planned and allocated in the current fiscal year
Unbudgeted: Requires new budget allocation or reallocation from other initiatives
Figure 2: Budgetary Timing Diagram
This distinction dramatically impacts who needs to approve the purchase. Unbudgeted items almost always require higher-level approval – typically at the CISO level for any significant expenditure, as they have the authority to reallocate funds or tap into contingency budgets.
The Cross-Organizational Challenge
A critical dimension often overlooked in enterprise security sales is cross-organizational dynamics.
When security purchases span multiple departments (e.g., budget from Compliance, implementation by Engineering), the buyer hierarchy becomes more complex. Moving funds between departmental budgets often requires executive approval above the standard buyer level.
Different departments operate with separate success metrics, priorities, and approval chains. What solves one team’s problems may create work for another with no benefit to their goals. These cross-organizational deals typically extend sales cycles by 30-50%.
For vendors navigating these scenarios, success depends on mapping all stakeholders across departments, creating targeted value propositions for each group, and sometimes elevating deals to executives who can resolve cross-departmental conflicts.
The Cost of Sale Framework
As solutions become more enterprise-focused, the cost of sale increases dramatically.
Figure 3: Cost of Sale Diagram
This framework illustrates a critical principle: The cost of sale must be aligned with the buyer level.
For solutions with a higher cost of sale (requiring more sales personnel time, longer sales cycles, more supporting resources), vendors must sell higher in the organization to ensure deal sizes justify these costs.
Key components affecting cost of sale include:
Sales personnel salary
Number of accounts per sales rep
Sales cycle length
Supporting resources required
This explains why enterprise security vendors selling complex solutions must target the CISO budget – it’s the only way to recoup their significant cost of sale.
Relationship Dynamics and Timing Considerations
While understanding the buyer hierarchy is essential, most successful enterprise security deals don’t happen solely through identifying the right level in an organization.
Figure 4: Cost of Sale Diagram
Two critical factors often determine success:
Relationship Development: Successful sales rarely happen in a transactional manner. They require:
Building trust through consistent value delivery before the sale
Understanding the internal politics and relationships between champions and buyers
Developing multiple organizational touchpoints beyond just the champion
Recognizing the personal career motivations of both champions and buyers
Timing Alignment: Even perfect solutions fail when timing is wrong:
Budget cycle alignment is critical – engage 3-6 months before annual planning
Crisis or incident response periods can accelerate purchases or freeze them
Organizational changes (new leadership, restructuring) create both opportunities and risks
Regulatory deadlines often drive urgent security investments
The most effective security vendors don’t just target the right level in the hierarchy – they strategically time their engagements and invest in relationship development that transcends organizational charts.
Practical Application
For security vendors, this framework provides practical guidance:
Know your buyer level: Based on your solution’s price point and complexity, identify your primary buyer persona (Manager, Director, or CISO)
Target champions appropriately: Ensure your technical messaging resonates with the people who will evaluate and champion your solution
Align marketing to both: Create distinct messaging for champions (technical value) and buyers (business value)
Understand the budget cycle: Time your sales efforts to align with budget planning for better success with larger deals
Match sales approach to cost structure: Ensure your go-to-market approach and resources match your cost of sale
By aligning your sales and marketing efforts with these buyer dynamics, you’ll significantly improve your efficiency and close rates in the enterprise security market.
Security used to be something we tried to bolt on to inherently insecure systems. In the 1990s, many believed that if we simply patched enough holes and set up enough firewalls, we could protect almost anything. Today, hard-won experience has shown that secure-by-design is the only sustainable path forward. Rather than treating security as an afterthought, we need to bake it into a system’s very foundation—from its initial design to its day-to-day operation.
Yet even the best security technology can fail to catch on if no one understands its value. In my time in the field I’ve seen a recurring theme: great solutions often falter because they aren’t communicated effectively to the right audiences. Whether you’re a security entrepreneur, an in-house security architect, or part of a larger development team, you’ll likely need to equip three distinct groups with the right messaging: the Technical Champion, the Economic Buyer, and the Broader Market. If any of them fail to see why—and how—your solution matters, momentum stalls.
From Bolt-On to Secure-by-Design
The security industry has undergone a massive shift, moving away from the idea that you can simply bolt on protection to an already flawed system. Instead, we now realize that security must be designed in from the start. This demands a lifecycle approach—it’s not enough to fix bugs after deployment or put a facade in front of a service. We have to consider how software is built, tested, deployed, and maintained over time.
This evolution requires cultural change: security can’t just live in a silo; it has to be woven into product development, operations, and even business strategy. Perhaps most importantly, we’ve learned that people, processes, and communication strategies are just as important as technology choices.
This shift has raised the bar. It’s no longer sufficient to show that your solution works; you must show how it seamlessly integrates into existing workflows, consider the entire use lifecycle, supports future needs, and gets buy-in across multiple levels of an organization.
The Three Audiences You Need to Win Over
The Technical Champion (80% Tech / 20% Business)
Your security solution will often catch the eye of a deeply technical person first. This might be a security engineer who’s tired of patching the same vulnerabilities or a software architect who sees design flaws that keep repeating. They’re your first and most crucial ally.
Technical champions need more than promises—they need proof. They want detailed demos showing real-world scenarios, sample configurations they can experiment with, and pilot environments where they can test thoroughly. Give them architecture diagrams that satisfy their technical depth, comprehensive documentation that anticipates their questions, and a clear roadmap showing how you’ll address emerging threats and scale for future needs.
Integration concerns keep champions awake at night. They need to understand exactly how your solution will mesh with existing systems, what the deployment strategy looks like, and who owns responsibility for updates and patches. Address their concerns about learning curves head-on with clear documentation and practical migration paths.
While technology drives their interest, champions eventually have to justify their choices to management. Give them a concise one-pager that frames the returns in business terms: reduced incident response time, prevented security gaps, and automated fixes that save precious engineer hours.
Why This Matters: When you equip your champion with the right resources, they become heroes inside their organizations. They’re the one who discovered that crucial solution before a major breach, who saved the team countless hours of manual work, who saw the strategic threat before anyone else. That kind of impact directly translates to recognition, promotions, and career advancement. The champion who successfully implements a game-changing security solution often becomes the go-to expert, earning both peer respect and management attention. When you help a champion shine like this, they’ll pull your solution along with them as they climb the organizational ladder.
The Economic Buyer (20% Tech / 80% Business)
A passionate champion isn’t always the one holding the purse strings. Often, budget is controlled by directors, VPs, or executives who juggle competing priorities and are measured by overall business outcomes, not technical elegance.
Your buyer needs a concise, compelling story about how this investment reduces risk, saves costs, or positions the company advantageously. Frame everything in terms of bottom-line impact: quantifiable labor hours saved, reduced compliance burdens, and concrete return on investment timelines.
Even without extensive case studies, you can build confidence through hypothetical or pilot data. Paint a clear picture: “Similar environments have seen 30% reduction in incident response time” or “Based on initial testing, we project 40% fewer false positives.” Consider proposing a small pilot or staged rollout—once they see quick wins scaling up becomes an easier sell.
Why This Matters: When buyers successfully champion a security solution, they transform from budget gatekeepers into strategic leaders in the eyes of executive management. They become known as the one who not only protected the company but showed real business vision. This reputation for combining security insight with business acumen often fast-tracks their career progression. A buyer who can consistently tell compelling business stories—especially about transformative security investments—quickly gets noticed by the C-suite. By helping them achieve these wins, you’re not just securing a deal; you’re empowering their journey to higher organizational levels. And as they advance, they’ll bring your solution with them to every new role and company they touch.
The Broader Market: Present, Teach, and Farm
While winning over individual champions and buyers is crucial, certain security approaches need industry-wide acceptance to truly succeed. Think of encryption standards, identity protocols, and AI based security research tools—these changed the world only after enough people, in multiple communities, embraced them.
Build visibility through consistent conference presentations, industry webinars, and local security meetups. Even with novel technologies, walking people through hypothetical deployments or pilot results builds confidence. Panels and Q&A sessions demonstrate your openness to tough questions and deep understanding of the problems you’re solving.
Make your message easy to spread and digest. While detailed whitepapers have their place, supplement them with short video demonstrations, clear infographics, and focused blog posts that capture your solution’s essence quickly. Sometimes a two-minute video demonstration or one-page technical overview sparks more interest than an extensive document.
Think of education as planting seeds—not every seed sprouts immediately, but consistent knowledge sharing shapes how an entire field thinks about security over time. Engage thoughtfully on social media, address skepticism head-on, and highlight relevant use cases that resonate with industry trends. Consider aligning with open-source projects, industry consortiums, or standards bodies to amplify your reach.
Why This Matters: By consistently educating and contributing to the community dialogue, you create opportunities for everyone involved to shine. Your champions become recognized thought leaders, speaking at major conferences about their successful implementations. Your buyers get profiled in industry publications for their strategic vision. Your early adopters become the experts everyone else consults. This creates a powerful feedback loop where community advocacy not only drives adoption but establishes reputations and advances careers. The security professionals who help establish new industry norms often find themselves leading the next wave of innovation—and they remember who helped them get there.
Overcoming Common Challenges
The “Not Invented Here” Mindset
Security professionals excel at finding flaws, tearing down systems, and building their own solutions. While this breaker mindset is valuable for discovering vulnerabilities, it can lead to the “Not Invented Here” syndrome: a belief that external solutions can’t possibly be as good as something built in-house.
The key is acknowledging and respecting this culture. Offer ways for teams to test, audit, or customize your solution so it doesn’t feel like an opaque black box. Show them how your dedicated support, updates, and roadmap maintenance can actually free their talent to focus on unique, high-value problems instead of maintaining yet another in-house tool.
Position yourself as a partner rather than a replacement. Your goal isn’t to diminish their expertise—it’s to provide specialized capabilities that complement their strengths. When teams see how your solution lets them focus on strategic priorities instead of routine maintenance, resistance often transforms into enthusiasm.
The Platform vs. Product Dilemma
A common pitfall in security (and tech in general) is trying to build a comprehensive platform before solving a single, specific problem. While platforms can be powerful, they require critical mass and broad ecosystem support to succeed. Many promising solutions have faltered by trying to do too much too soon.
Instead, focus on addressing one pressing need exceptionally well. This approach lets you deliver value quickly and build credibility through concrete wins. Once you’ve proven your worth in a specific area, you can naturally expand into adjacent problems. You might have a grand vision for a security platform, but keep your initial messaging focused on immediate, tangible benefits.
Navigating Cross-Organizational Dependencies
Cross-team dynamics can derail implementations in two common ways: operational questions like “Who will manage the database?” and adoption misalignment where one team (like Compliance) holds the budget while another (like Engineering) must use the solution. Either can stall deals for months.
Design your proof of value (POV) deployments to minimize cross-team dependencies. The faster a champion can demonstrate value without requiring multiple department sign-offs, the better. Start small within a single team’s control, then scale across organizational boundaries as value is proven.
Understand ownership boundaries early: Who handles infrastructure? Deployment? Access control? Incident response? What security and operational checklists must be met for production? Help your champion map these responsibilities to speed implementation and navigate political waters.
The Timing and Budget Challenge
Success often depends on engaging at the right time in the organization’s budgeting cycle. Either align with existing budget line items or engage early enough to help secure new ones through education. Otherwise, your champion may be stuck trying to spend someone else’s budget—a path that rarely succeeds. Remember that budget processes in large organizations can take 6-12 months, so timing your engagement is crucial.
The Production Readiness Gap
A signed deal isn’t the finish line—it’s where the real work begins. Without successful production deployment, you won’t get renewals and often can’t recognize revenue. Know your readiness for the scale requirements of target customers before engaging deeply in sales.
Be honest about your production readiness. Can you handle their volume? Meet their SLAs? Support their compliance requirements? Have you tested at similar scale? If not, you risk burning valuable market trust and champion relationships. Sometimes the best strategy is declining opportunities until you’re truly ready for that tier of customer.
Having a clear path from POV to production is critical. Document your readiness criteria, reference architectures, and scaling capabilities. Help champions understand and navigate the journey from pilot to full deployment. Remember: a successful small customer in production is often more valuable than a large customer stuck in pilot or never deploys into production and does not renew.
Overcoming Entrenched Solutions
One of the toughest challenges isn’t technical—it’s navigating around those whose roles are built on maintaining the status quo. Even when existing solutions have clear gaps (like secrets being unprotected 99% of their lifecycle), the facts often don’t matter because someone’s job security depends on not acknowledging them.
This requires a careful balance. Rather than directly challenging the current approach, focus on complementing and expanding their security coverage. Position your solution as helping them achieve their broader mission of protecting the organization, not replacing their existing responsibilities. Show how they can evolve their role alongside your solution, becoming the champion of a more comprehensive security strategy rather than just maintaining the current tools.
Putting It All Together
After three decades in security, one insight stands out: success depends as much on communication as on code. You might have the most innovative approach, the sleekest dashboard, or a bulletproof protocol—but if nobody can articulate its value to decision-makers and colleagues, it might remain stuck at the proof-of-concept stage or sitting on a shelf.
Your technical champion needs robust materials and sufficient business context to advocate internally. Your economic buyer needs clear, ROI-focused narratives supported by concrete outcomes. And the broader market needs consistent education through various channels to understand and embrace new approaches.
Stay mindful of cultural barriers like “Not Invented Here” and resist the urge to solve everything at once. Focus on practical use cases, maintain consistent messaging across audiences, and show how each stakeholder personally benefits from your solution. This transforms curiosity into momentum, driving not just adoption but industry evolution.
Take a moment to assess your approach: Have you given your champion everything needed to succeed—technical depth, migration guidance, and business context? Does your buyer have a compelling, ROI-focused pitch built on solid data? Are you effectively sharing your story with the broader market through multiple channels?
If you’re missing any of these elements, now is the time to refine your strategy. By engaging these three audiences effectively, addressing cultural barriers directly, and maintaining focus on tangible problems, you’ll help advance security one success story at a time.
Jim Barksdale famously said “All money is made through bundling and unbundling,” and this dynamic is evident in the Non-Human Identity (NHI) market. Cryptography management, privileged access management, and certificate lifecycle solutions are being redefined under a higher-level taxonomy. These functions, once viewed as isolated, are increasingly integrated into broader frameworks addressing identity, governance, and security holistically, reflecting the market’s shift toward unified and specialized solutions.
Cloud providers dominate in offering integrated solutions across categories, but these are often limited and focus on cost-recovery pricing to encourage adoption of their real money-makers like compute, storage, network, databases, and these days AI. They frequently provide just enough to facilitate a single project’s adoption, leaving opportunities for other vendors. For instance, Microsoft’s push to migrate enterprises from on-premises Active Directory to its cloud offering presents an opportunity to unbundle within the NHI IAM space. By focusing narrowly on migrating existing infrastructures rather than reimagining solutions from first principles to meet modern usage patterns, Microsoft has created gaps that smaller, more agile providers can exploit. Similarly, regulatory pressures and the rise of AI-driven, agentic workloads are driving demand for advanced workload authentication, creating further opportunities for specialized providers to deliver tailored solutions. Meanwhile, established players like CyberArk and Keyfactor have pursued acquisitions, such as Keyfactor’s merger with PrimeKey, to bundle new capabilities and remain competitive. However, the integration complexity of these acquisitions often leaves room for focused providers to address modern, cloud-native demands more effectively.
At the same time, traditional cryptography management companies have been so focused on their existing Key Management System (KMS) and Hardware Security Module (HSM) offerings that they have largely ignored broader unmet needs in the market, prioritizing feature expansion and acquisitions aimed at chasing smaller competitors. This narrow focus has left significant gaps in visibility, particularly around cryptographic assets and risks, creating fertile ground for new solutions focused on cryptography discovery, automated inventory management, and preparation for post-quantum cryptography.
Capital allocation, on the other hand, highlights category focus and growth potential. Seed and Series A investments underscore the dynamic opportunities created by unbundling, as well as the constraints faced by larger vendors burdened with legacy products that make it harder to truly innovate due to existing commercial obligations in the same space. In contrast, private equity activity targets larger bundling opportunities, enabling less agile and more mature market leaders to remain relevant by scaling established solutions or consolidating fragmented players. These stages illustrate the market’s balance between early-stage innovation and late-stage consolidation, driven by the growing demand for unified, cloud-native identity and governance solutions.
These patterns of bundling and unbundling are organic and continual, offering just one lens on the evolving dynamics of this market. While the NHI market appears new, it is, in fact, a natural evolution of existing identity governance patterns, driven by the growing demand for unified, cloud-native identity and governance solutions. This evolution underscores the balance between early-stage innovation and late-stage consolidation, as new entrants and established players alike navigate the opportunities created by shifting market dynamics.
A common theme in conversations about product managers is the notion that they don’t need to be technical; they just need to bridge the gap between technical and non-technical teams. In my experience, particularly with enterprise and security products, this is a complete fallacy. Part of why this argument persists is the misconception that all product management is the same.
If you’re working on a 10-year-old product based on 20-year-old deployment patterns—and this might be hard to hear—chances are you’re not innovating. Instead, you’re managing customer requests and operating within the constraints of the bureaucracy you’re part of. Your roadmap likely consists of a mix of customer demands and features cloned from smaller competitors.
Another reason this perspective persists is that many organizations divide product managers into two categories: inbound and outbound. Outbound product managers are this decade’s version of product MBAs. They often have a limited understanding of their customers and their needs, instead focusing on systematizing a go-to-market strategy based on abstractions.
In the problem domain of enterprise and security—especially in small to medium-sized companies, where innovation tends to happen—there is no substitute for being an expert in what you’re building and selling. One of the most important things to understand is your customer: their pains, their constraints, and the schedules they operate within. The thing is, your customer isn’t just one person in an enterprise sale. As I’ve written before, at a minimum, you’re dealing with an economic buyer and a champion in any sale. If you’re lucky, you have many champions. And if you think strategically, you can even identify your champions’ champions within the sale.
This requires you to understand everyone’s job and perspective. If you don’t understand the technology or problem domain natively, you will always struggle—and likely fail—especially in smaller, early-stage companies.
Don’t get me wrong: once a company finds product-market fit and has a reproducible recipe for selling into organizations—or as the market evolves and expectations for a product in a given segment become standardized—it becomes less necessary. But even then, bringing that expertise to the table remains a powerful force multiplier that enables organizations lucky enough to have these resources to vastly outperform much larger and better-funded competitors.
Since I spend most of my time these days with smaller companies or very large companies looking to become more competitive again, all I can say is this: without the right product leaders, the best you can hope for is growing at the pace of your overall market and maintaining the status quo.
Incident response is notoriously challenging, and with the rise in public reporting obligations, the stakes have never been higher. In the WebPKI world, mishandling incidents can severely damage a company’s reputation and revenue, and sometimes even end a business. The Cyber Incident Reporting for Critical Infrastructure Act of 2022 has intensified this pressure, requiring some companies to report significant breaches to CISA within 72 hours. This isn’t just about meeting deadlines. The stakes are high, and the pressure is on. Look at the recent actions of the Cyber Safety Review Board (CSRB), which investigates major cyber incidents much like how plane crashes are scrutinized. The recent case of Entrust’s cascade of incidents in the WebPKI ecosystem, and the scrutiny they have gone under as a result, shows how critical it is to respond professionally, humbly, swiftly, and transparently. The takeaway? If you don’t respond adequately to an incident, someone else might do it for you, and even if not, mishandling can result in things spiraling out of control.
The Complexity of Public Reporting
Public reports attract attention from all sides—customers, investors, regulators, the media, and more. This means your incident response team must be thorough and meticulous, leaving no stone unturned. Balancing transparency with protecting your organization’s image is critical. A well-managed incident can build trust, while a poorly handled one can cause long-term damage.
Public disclosures also potentially come with legal ramifications. Everything must be vetted to ensure compliance and mitigate potential liabilities. With tight timelines like the CISA 72-hour reporting requirement, there’s little room for error. Gathering and verifying information quickly is challenging, especially when the situation is still unfolding. Moreover, public reporting requires seamless coordination between IT, legal, PR, and executive teams. Miscommunication can lead to inconsistencies and errors in the public narrative.
The Role of Blameless Post Mortems
Blameless post-mortems are invaluable. When there’s no fear of blame, team members are more likely to share all relevant details, leading to a clearer understanding of the incident. These post-mortems focus on systemic issues rather than pointing fingers, which helps prevent similar problems in the future. By fostering a learning culture, teams can improve continuously without worrying about punitive actions.
It’s essential to identify the root causes of incidents and ensure they are fixed durably across the entire system. When the same issues happen repeatedly, it indicates that the true root causes were not addressed. Implementing automation and tooling wherever possible is crucial so that you always have the information needed to respond quickly. Incidents that close quickly have minimal impact, whereas those that linger can severely damage a business.
Knowing they won’t be blamed, team members can contribute more calmly and effectively, improving the quality of the response. This approach also encourages thorough documentation, creating valuable resources for future incidents.
Evolving Public Reporting Obligations
New regulations demand greater transparency and accountability, pushing organizations to improve their security practices. With detailed and timely information, organizations can better assess and manage their risks. The added legal and regulatory pressure leads to faster and more comprehensive responses, reducing the time vulnerabilities are left unaddressed. However, these strict timelines and detailed disclosures increase stress on incident response teams, necessitating better support and processes. Additionally, when there are systemic failures in an organization, one incident can lead to others, overwhelming stakeholders and making it challenging to prioritize critical issues.
Importance of a Strong Communication Strategy
Maintaining trust and credibility through transparent and timely communication is essential. Clear messaging prevents misinformation and reduces panic, ensuring stakeholders understand the situation and response efforts. Effective communication can mitigate negative perceptions and protect your brand, even in the face of serious incidents. Proper communication also helps ensure compliance with legal and regulatory requirements, avoiding fines and legal issues. Keeping stakeholders informed supports overall recovery efforts by maintaining engagement and trust.
Implementing Effective Communication Strategies
Preparation is key. Develop a crisis communication plan that outlines roles, responsibilities, and procedures. Scenario planning helps anticipate and prepare for different types of incidents. Speed and accuracy are critical. Provide regular updates as the situation evolves to keep stakeholders informed.
Consistency in messaging is vital. Ensure all communications are aligned across all channels and avoid jargon. Transparency and honesty are crucial—acknowledge the incident and its impact, and explain the steps being taken to address it. Showing empathy for those affected and offering support and resources demonstrates that your organization cares. Keep employees informed about the incident and the organization’s response through regular internal briefings to ensure all teams are aligned and prepared to handle inquiries.
Handling Open Public Dialogues
Involving skilled communicators who understand both the technical and broader implications of incidents is crucial. Coordination between legal and PR teams ensures that messaging is clear and accurate. Implement robust systems to track all public obligations, deadlines, and commitments, with regular audits to ensure compliance and documentation. Prepare for potential delays or issues with contingency plans and pre-drafted communications, and proactively communicate if commitments cannot be met on time.
Communication with Major Customers: It often becomes necessary to keep major customers in the loop, providing them with timely updates and reassurances about the steps being taken. Build plans for how to proactively do this successfully.
Clear Objectives and Measurable Criteria: Define clear and measurable criteria for what good public responses look like and manage to this. This helps ensure that all communications are effective and meet the required standards.
External Expert Review: Retain external experts to review your incidents with a critical eye whenever possible. This helps catch misframing and gaps before you step into a tar pit.
Clarity for External Parties: Remember that external parties won’t understand your organizational structure and team dynamics. It’s your responsibility to provide them with the information needed to interpret the report the way you intended.
Sign-Off Process: Have a sign-off process for stakeholders, including technical, business, and legal teams, to ensure the report provides the right level of information needed by its readers.
Track Commitments and Public Obligations: Track all your commitments and public obligations and respond by any committed dates. If you can’t meet a deadline, let the public know ahead of time.
In the end, humility, transparency, and accountability are what make a successful public report.
Case Study: WoSign’s Non-Recoverable Loss of Trust
Incident: WoSign was caught lying about several aspects of their certificate issuance practices, leading to a total non-recoverable loss of trust from major browsers and ultimately their removal from trusted root stores.
Outcome: The incident led to a complete loss of trust from major browsers.
Impact: This example underscores the importance of transparency and honesty in public reporting, as once trust is lost, it may never be regained.
Case Study: Symantec and the Erosion of Trust
Incident: Symantec, one of the largest Certificate Authorities (CAs), improperly issued numerous certificates, including test certificates for domains not owned by Symantec and certificates for Google domains without proper authorization. Their non-transparent, combative behavior, and unwillingness to identify the true root cause publicly led to their ultimate distrust.
Outcome: This resulted in a significant loss of trust in Symantec’s CA operations. Both Google Chrome and Mozilla Firefox announced plans to distrust Symantec certificates, forcing the company to transition its CA business to DigiCert.
Impact: The incident severely damaged Symantec’s reputation in the WebPKI community and resulted in operational and financial setbacks, leading to the sale of their CA business.
Conclusion
Navigating public reporting obligations in WebPKI and other sectors is undeniably complex and challenging. However, by prioritizing clear, honest communication and involving the right professionals, organizations can effectively manage these complexities. Rigorous tracking of obligations, proactive and transparent communication, and a robust incident response plan are critical. Case studies like those of WoSign and Symantec underscore the importance of transparency and honesty—once trust is lost, it may never be regained.
To maintain trust and protect your brand, develop a crisis communication plan that prioritizes speed, accuracy, and empathy. Consistent, transparent messaging across all channels is vital, and preparing for potential incidents with scenario planning can make all the difference. Remember, how you handle an incident can build or break trust. By learning from past mistakes and focusing on continuous improvement, organizations can navigate public reporting obligations more effectively, ensuring they emerge stronger and more resilient.
Despite today’s widespread use of open-source software, most software is still delivered in binary form. This includes everything from the foundational firmware of our computers to the applications we use for work, extending all the way to the containers running our server software in the cloud.
A significant challenge arises when even if the source code of the software is available, reproducing the exact binary from it is often impossible. Consequently, companies and users are essentially operating on blind faith regarding any qualitative or quantitative assurances received from software suppliers. This stark reality played a critical role in the rapid and broad spread of the SolarWinds incident across the industry.
The SolarWinds Wake-Up Call
The SolarWinds attack underscored the risks inherent in placing our trust in software systems. In this incident, attackers infiltrated build systems, embedding malware into the legitimate SolarWinds software. Customers updating to the latest software version unwittingly became victims in this attack chain. It’s crucial to acknowledge that targeting a software supply chain for widespread distribution is not a new tactic. Ken Thompson, in his 1984 Turing Award Lecture, famously stated, “No amount of source-level verification or scrutiny will protect you from using untrusted code.” Regrettably, our approaches to this challenge haven’t significantly evolved since then.
Progress in the domain of supply chain security was initially slow. In 1996, Microsoft began promoting the concept of code signing with its Authenticode support, allowing customers to verify that their software hadn’t been altered post-distribution. Subsequently, the open-source movement gained traction, particularly following the release of Netscape Navigator’s source code. Over the next two decades, the adoption of open source, and to a lesser extent, code signing increased. The use of interpreted languages aided in understanding software operations, but as software grew in size and complexity, the demand for software engineers began to outstrip the supply. The adage “Given enough eyeballs, all bugs are shallow” suggests that greater openness can enhance security, yet the industry has struggled to develop a talent pool and incentive models robust enough to leverage source code availability effectively.
Before the SolarWinds incident, the industry, apart from some security engineers advocating for practices like reproducible builds, memory-safe languages, and interpreted languages, largely overlooked the topic of supply chain security. Notable initiatives like Google’s work on Binary Transparency, which predates SolarWinds, began to create an environment for broader adoption of code signing-like technologies with efforts like Go SumDB, SigStore, and Android’s Binary Transparency (each of which I had the opportunity to contribute to). However, even these solutions don’t fully address the challenge of understanding the issues within a binary, a problem that remains at the forefront of security.
The industry’s response to SolarWinds also included embracing the concept of Software Bill of Materials (SBOM). These artifacts, envisioned to be produced by the build system, document the, often third-party, components used in software. However, this approach faces challenges, such as the possibility of attackers manipulating SBOMs if they compromise the build system.
The complexity of compiled software adds another layer of difficulty. Each compiled dependency has its own dependencies, not all of which are publicly declared, as is the case with static dependencies. When software is compiled, only portions of the dependencies that are used get included, potentially incorporating multiple versions of a single dependency into the final binary. This complexity makes simple statements about software components, like “I use OpenSSL 1.0,” inaccurate for even moderately complex code. Moreover, the information derived from SBOMs is often not actionable. Without access to all sources or the ability to build binaries independently, users are left with CVE lists that provide more noise than actionable insight.
To make things worse compilers, through the optimization of builds can even remove security fixes that developers carefully put in to mitigate known issues, for example, freeing memory to keep keys cryptographic keys and passwords from getting paged to disk.
The Critical Role of Binary Analysis
If all we have is a binary, the only way to understand the risks it represents is to analyze it in the same way an attacker would. However, doing this at scale and making the analysis actionable is challenging. Recent advancements in machine learning and language development are key to addressing this challenge.
Currently, tools that operate on binaries alone fall into two categories. The first are solutions akin to 1990s antivirus programs – matching binaries to known issues. The second category helps skilled professionals reverse engineer the binary’s contents more quickly.
Both categories have struggled to keep pace with the rapid changes in software over the past few decades. A new category of tools is emerging, led by companies like Binarly, which I advise. Binarly’s approach to automated binary analysis began with key goals such as achieving processor architecture independence and language independence. This enables the analysis of binaries across different architectures without duplicating threat intelligence and identifying insecure patterns stemming from ported code or common insecure Stack Overflow examples. Identifying static dependencies and which parts of them are used in a binary is both challenging and crucial for understanding the security issues that lie beneath the surface.
Their approach is remarkable in its ability to detect “known unknowns,” enabling the identification of classes of security vulnerabilities within a binary alone. Furthermore, through symbolic execution, they can perform reachability analysis, ensuring that flagged issues are not just theoretical but can potentially be exploited by attackers.
Though their approaches are not firmware-specific, Firmware is a great example of the problems that come from binary-only distributions and customers’ reliance on blind faith that their vendors are making the right security investments. It is their unique approach to binary analysis that has enabled them to file and report more CVEs in the last two years than have ever been reported before.
Binary analysis of this kind is crucial as it scrutinizes software in its final, executable form—the form in which attackers interact with it.
Conclusion
The lesson from the SolarWinds attack is clear: no build system-based approach to articulate dependencies is entirely secure. Ken Thompson’s 1984 assertion about the limitations of trusting any code you didn’t produce yourself remains relevant. In a world where software vulnerabilities have extensive and far-reaching impacts, binary analysis is indispensable. Binarly’s approach represents a paradigm shift in how we secure software, offering a more robust and comprehensive solution in our increasingly connected world.
