Jeff Williams writes about application security, including runtime protection for software and APIs, vulnerability response, and how AI may change secure software development.
Jeff Williams is most useful for technical content on runtime application security, software liability, and AI security.
Best for
A cybersecurity vendor selling runtime application security and assurance-based development to enterprise security buyers.
Not for
A WAF or perimeter-only security vendor, or a general B2B SaaS marketing audience.
Key takeaways
Changing a P to %50 can bypass a WAF, but runtime controls see decoded input.
AI-assisted vulnerability discovery could reduce protection once provided by software complexity, like a coral reef.
EU Product Liability Directive applies to software and AI on December 9, 2026.
Check first: Confirm whether they have a public sponsorship format, rate card, or partnership intake.
Main ideas
Stop trying to fix every vulnerability; protect the running app · WAFs cannot see what the application sees · Software liability is arriving on a fixed calendar
Jeff Williams writes about application security, runtime protection for software and APIs, software liability, and the future of secure development.
His posts connect practical security problems—such as WAF bypasses and exposed vulnerabilities—to broader questions about regulation and how organizations can prove software is secure.
He also says he wrote the OWASP Secure Software Contract Annex more than 20 years ago, linking his current discussion of product liability to earlier work on responsibility for security flaws.
Follow his work for a practitioner’s perspective on why runtime visibility matters and how AI may change both software attacks and security assurance.
Williams connects technical detail to operational and legal consequences.
In one post, he explains how changing a “P” to “%50” can bypass a WAF, then describes how runtime controls can see decoded input inside the application.
In another, he uses a coral-reef analogy to explain why AI-assisted vulnerability discovery could reduce the protection once provided by software complexity.
His liability post brings the argument back to accountability, distinguishing knowable defects from issues that could not reasonably have been discovered.
Together, these examples show a consistent approach: explain the mechanism, identify what it means for security teams, and ask what should change.
Some posts are explicitly promotional for Contrast products, so readers should distinguish product claims from the broader arguments.
The reviewed material does not establish a fuller account of Williams’s career or other signature work; a publisher or other primary source about the OWASP annex would help confirm its context and significance.
Jeff Williams argues that vulnerability discovery and exploitation are speeding up while patching cannot keep pace, so security has to move inside the running application — and eventually into software factories that generate their own assurance evidence.
Read more
Two deadlines run through much of the material: the EU Product Liability Directive applying to software and AI on December 9, 2026, and the EU Cyber Resilience Act's 24-hour and 72-hour incident reporting duties. The posts are a mix of technical argument, legal countdown, and product promotion for runtime security tools.
Stop trying to fix every vulnerability; protect the running app
Jeff Williams argues that adding runtime security to applications and APIs is a practical alternative to a "fix all vulns" strategy.
Read more
With a one-time install, they say, a team can mitigate current and future CVEs in production without disruption, instead of scanning and patching continuously.
The argument rests on runtime visibility: which libraries are present in a running application, which of those are actually in use, which CVEs in them are exposed, and which exposed CVEs have been attacked.
Jeff Williams says that narrows attention to roughly the 1-2% of problems that matter.
A post highlighting a demo from Dave describes the tool identifying all libraries present in runtime, which are in use, which CVEs are exposed, and which exposed CVEs have been attacked, and states the performance impact is under 20 nanoseconds.
Jeff Williams argues that web application firewalls cannot reliably protect modern apps and APIs for two reasons.
Read more
First, an "impedance mismatch": the WAF inspects different data than the code actually processes.
Second, request data is no longer simple name=value pairs but complex structures in multiple serialization formats the WAF cannot look into.
The proposed answer, application detection and response (ADR), works from inside running code, so it sees data after it has been decoded, and puts deserialization into a microsandbox that prevents harmful behavior.
Jeff Williams extends the claim to custom code and library vulnerabilities, saying ADR keeps them from being exploited.
A mass exploitation campaign by ShinyHunters against CVE-2026-35273 bypassed a PeopleSoft WAF by changing a "P" to "%50", then used unsafe deserialization to launch native processes and create webshells. Jeff Williams adds that they used the same encoding trick in the early 2000s to reach unauthorized .jsp endpoints.
Software liability is arriving on a fixed calendar
Jeff Williams treats software liability as an urgent deadline rather than a distant policy debate.
Read more
They count down to December 9, 2026, when the EU Product Liability Directive starts applying to new products including software and AI systems, and explain the Development Risk Defense: if the state of scientific and technical knowledge was not advanced enough to discover the defect, a producer may have a defense.
They compare that with the OWASP Secure Software Contract Annex, which they say they wrote more than 20 years ago, and its concept of "Novel Security Issues."
The SSCA addressed contractual liability; the PLD creates statutory liability, almost like a non-waivable default term.
The stated principle is that liability should fall on the party who can most easily avoid the costs when a defect was, or should have been, knowable.
Jeff Williams asks directly whether a rogue AI agent counts as a "defect" under the PLD, says the courts will ultimately decide, and says they do not know whether it qualifies. A second post marks September 11 as the start of the CRA's reporting obligations: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, and a detailed notification within 72 hours.
The same liability question runs across roughly two decades of their work: the contract annex assigned responsibility for vulnerabilities nobody could reasonably have known about, and Jeff Williams argues the PLD reaches a similar result through statute instead of contract.
AI is collapsing the window that made software accidentally safe
Jeff Williams argues that software stayed relatively safe not because it was secure but because vulnerability analysis was slow: mapping paths through complex applications, dependencies, and environments took attackers time and effort.
Read more
Automated discovery changes that calculus.
They expect attackers to gain comparable mapping capability quickly, so the exposure window collapses.
AI is also part of the remedy — Jeff Williams hopes it helps work through the vulnerability backlog over the next few years — but says that will take time, and recommends updating AppSec programs for what they call the "Dark Software Factory" and adding runtime security at the application layer in the meantime.
The coral reef analogy: a messy, hard-to-navigate reef keeps most sharks out, which gives fish a form of accidental safety. Jeff Williams describes Anthropic's Mythos as building an automatic reef mapper, expects the sharks to get "Google Maps" into the reef shortly, and says organizations still have to stop the sharks while the industry patches the reef.
The end state is an assurance-based software factory, not better remediation
Jeff Williams calls remediation "yesterday's problem."
Read more
Their longer-range argument is that AI will streamline the workflows that make up secure by design into a software factory that autonomously produces good software from a specification and autonomously generates a compelling assurance case.
That case would identify threats, the defenses against them, evidence that the defenses are correct and effective, and runtime data showing security in production.
Jeff Williams frames this as a shift from a negative, risk-management approach — "hacking ourselves secure" — to a positive, assurance-based one.
They say the shift will take many years not because the technology is missing, but because people, process, and security culture resist change.
Jeff Williams notes that Glasshouse may shake up the "penetrate and patch" hamster wheel of pain workflows somewhat, but argues that is yesterday's problem and the next domino is remediation itself.
This original answers what new software liability rules may mean for AppSec and AI security programs, and why an old OWASP contract annex is still relevant.
Read more
A newcomer should start here to understand Jeff Williams’s legal and risk framing before reading the more product-focused posts.
Jeff Williams counts down 76 days to the EU Product Liability Directive applying to new products, including software and AI systems, on December 9, 2026.
The post explains the Development Risk Defense: if scientific and technical knowledge was not advanced enough to discover the defect, a producer may have a defense.
Jeff Williams connects this to the OWASP Secure Software Contract Annex, which he says he wrote more than 20 years ago, and to the idea of “Novel Security Issues.”
The post notes that the SSCA dealt with contractual liability while the PLD creates statutory liability, almost like a non-waivable default term.
Jeff Williams says if a defect was knowable or should have been knowable, liability falls on the producer, and if it truly could not be discovered, that is different.
The post openly asks whether rogue-AI behavior is a “defect” and who can most easily avoid the costs.
For brands planning a campaign
A cybersecurity vendor can use this as a webinar or thought-leadership hook on AI liability, liability-ready runtime evidence, and assurance cases. It pairs well with a legal, risk, or compliance speaker who can discuss how software producers should prepare for the PLD and CRA obligations.
This original answers why AI may change the speed and economics of exploitation, and why runtime security is presented as a practical response.
Read more
It is a clear starting point for a general reader who wants Jeff Williams’s view on where application security is heading.
Jeff Williams calls the Mythos/Glasswing announcement a wake-up call.
The post argues software stayed safe for a long time because vulnerability analysis was slow, not because code was secure.
Jeff Williams uses a coral reef analogy: the reef is messy and hard to navigate, so most sharks do not make it all the way in, and the complexity provides accidental safety.
With what Jeff Williams describes as Anthropic’s Mythos automatic reef mapper, the exposure window is collapsing.
The post expects attackers to get “Google Maps” into the reef and recommends updating AppSec programs for the “Dark Software Factory” and adding runtime security to the application layer.
Jeff Williams names ADR as a fast way to protect applications even when they have vulnerabilities.
For brands planning a campaign
This supports an urgency narrative for runtime security and AppSec modernization. A vendor could anchor a thought-leadership piece or webinar opening on why AI-assisted vulnerability discovery makes runtime protection more important, then demonstrate how runtime security changes the buyer’s risk calculation.
This original answers what Jeff Williams sees beyond current remediation workflows and why assurance cases matter.
Read more
A newcomer should read it to understand the long-range vision that connects the AI, liability, and runtime-security themes in the other posts.
Jeff Williams says Glasshouse may shake up the “penetrate and patch” hamster wheel of pain workflows, but calls that yesterday’s problem.
The post argues today’s problem is not just remediation.
Jeff Williams believes the endpoint is using AI to streamline all the security workflows that make up “secure by design” into a software factory that autonomously creates great software from a spec and also autonomously generates a compelling assurance case.
That assurance case would identify threats, defenses to those threats, evidence that defenses are correct and effective, and runtime data showing security in production.
Jeff Williams frames the shift from a negative “hacking ourselves secure” risk-management approach to a positive assurance-based approach as one that will take many years, not because the technology is missing, but because people, process, and culture in security are resistant to change.
For brands planning a campaign
This is useful for positioning around assurance-based development, AI-generated evidence, and organizational change. It can support a visionary keynote or executive webinar that moves the conversation beyond tool-level remediation and toward a software factory that produces security evidence by design.
This original answers how modern attacks evade WAFs and what runtime security does differently.
Read more
It is a strong starting point for a technical reader because it preserves the exact bypass and the operational consequence.
Jeff Williams describes a mass exploitation campaign by ShinyHunters against CVE-2026-35273.
The attackers bypass the PeopleSoft WAF by changing a “P” to “%50” and then use unsafe deserialization to launch native processes and create webshells.
Jeff Williams explains two reasons WAFs cannot reliably protect web apps and APIs against modern attacks: an “impedance mismatch” where the WAF sees different data than the code, and the fact that data going into apps and APIs is no longer simple name=value pairs but complex data structures in various serialization formats.
The post says ADR works from inside running code, sees data the way the code does after decoding, and puts deserialization in a microsandbox that prevents harmful behavior.
It promotes a free trial to see which CVEs are exposed at runtime, which have been attacked, and to prevent exploits.
For brands planning a campaign
This is a concrete technical demo or webinar story about WAF limitations and runtime application self-protection. A vendor can use the attack chain to show why runtime visibility and deserialization controls matter, then demonstrate how runtime security blocks exploitation even when custom code or library vulnerabilities exist.
This original answers what the EU CRA reporting deadlines require and what runtime visibility a producer needs to respond.
Read more
A general reader should start here for a concrete compliance deadline and the operational checklist Jeff Williams repeats in other posts.
Jeff Williams marks September 11 as the date the EU Cyber Resilience Act’s reporting obligations go into effect.
The post says software producers selling in the EU must report actively exploited vulnerabilities and severe incidents affecting product security.
An early warning is due within 24 hours of becoming aware, followed by a more detailed notification within 72 hours, both without undue delay.
Jeff Williams lists what a producer needs to respond quickly: exactly what libraries are in production, where app and API CVEs are, which CVEs are actually active and exposed, which CVEs are being attacked, and a real contextual risk score for each CVE.
The post promotes Contrast CVE Shield as free, continuous runtime security with no scanning, installable in minutes across Docker, Kubernetes, and Linux, with instant visibility across apps and APIs.
For brands planning a campaign
This supports a compliance-focused webinar, guide, or campaign around CRA readiness. A vendor can position runtime inventory and attack evidence as a practical way to meet reporting timelines, while keeping the message grounded in the specific 24-hour and 72-hour duties.
This original answers what the product capability looks like in practice and why runtime CVE prioritization is different from scanning.
Read more
A newcomer can start here for a short, concrete view of the claims Jeff Williams makes about speed and precision.
Jeff Williams highlights a demo showing Contrast CVE Shield identifying all libraries present in runtime, which of those libraries are in use, which CVEs in those libraries are exposed, and which of the exposed CVEs have been attacked.
The post says this lets teams focus on the 1-2% of problems that matter, with essentially zero performance impact under 20 nanoseconds.
Jeff Williams notes the tool is free and released for Java first, with other languages coming soon.
For brands planning a campaign
This is a ready-made demo asset for a webinar or product-led campaign. It supports messaging on runtime CVE prioritization, near-zero performance impact, and a free entry point that can lead into broader runtime security conversations.
This original answers the simplest version of why runtime security is worth considering.
Read more
A general reader can start here for a quick statement of the alternative before reading the more detailed CRA, WAF, and liability posts.
Jeff Williams gives a short version of the core runtime-security argument: adding runtime security to apps and APIs is a great alternative to the “fix all vulns” strategy. With a one-time install, the post says, a team can mitigate all current and future CVEs in production without disruption.
For brands planning a campaign
This is a concise boilerplate for campaign messaging that contrasts runtime mitigation with endless vulnerability remediation. It can be used as a short social proof point or as a simple explanation for buyers who are new to runtime security.
Runtime protection as an alternative to patching every vulnerability5
Free product-led CVE visibility for developers3
Software liability deadlines and the OWASP contract annex2
AI as both threat and solution in vulnerability discovery2
Why WAFs miss modern web and API attacks1
Assurance-based secure development as the longer-term shift1
Open questions and audience engagement1
Runtime protection as an alternative to patching every vulnerability
Jeff Williams repeatedly argues that adding runtime security to applications and APIs is a practical alternative to trying to fix every vulnerability.
Read more
The posts tie this to Contrast CVE Shield and ADR: a one-time install that can mitigate current and future CVEs in production, show which libraries are present and in use, identify which CVEs are exposed, and show which exposed CVEs have been attacked. Jeff Williams says this helps teams focus on the 1-2% of problems that matter and describes the performance impact as essentially zero, under 20 nanoseconds.
Product demonstration and direct comparison: the posts list runtime facts such as libraries present, libraries in use, exposed CVEs, and attacked CVEs, then contrast them with scanning or patching workflows.
For brands planning a campaign
For a vendor positioning runtime application security to enterprise buyers, Jeff Williams offers a concrete, product-led argument about patch fatigue.
A webinar could contrast a patch-everything strategy with runtime mitigation, using the library and CVE visibility chain and the performance claim as discussion points.
The campaign should let Jeff Williams demonstrate the runtime view rather than rely on abstract shift-left language.
In a post about a ShinyHunters mass exploitation campaign against CVE-2026-35273, Jeff Williams walks through a PeopleSoft WAF bypass that changes a P to %50 and then uses unsafe deserialization to launch native processes and create webshells.
Read more
The post argues that WAFs cannot reliably protect modern apps and APIs because of an impedance mismatch, where the WAF sees different data than the code, and because request data is no longer simple name=value pairs but complex structures in multiple serialization formats. Jeff Williams says ADR works from inside running code, sees data after it is decoded, and places deserialization in a microsandbox.
Exploit walkthrough plus first-person historical anecdote: Jeff Williams connects a current CVE exploitation to an encoding trick they say they used in the early 2000s.
For brands planning a campaign
This is strong technical evidence for a runtime security or app and API protection campaign.
A thought-leadership collaboration could use the WAF bypass example to explain why runtime instrumentation sees what a perimeter control cannot.
Enterprise buyers evaluating WAF replacement or augmentation may respond to a webinar built around decoding, deserialization, and runtime enforcement.
Software liability deadlines and the OWASP contract annex
Jeff Williams frames software liability as an urgent deadline.
Read more
One post counts 76 days until December 9, 2026, when the EU Product Liability Directive starts applying to new products including software and AI systems, and asks whether a rogue AI agent is a defect under the PLD.
Another post marks September 11 as the date EU Cyber Resilience Act reporting obligations begin, with an early warning due within 24 hours and a detailed notification within 72 hours.
Jeff Williams connects this to the OWASP Secure Software Contract Annex, which they say they wrote more than 20 years ago, and to the idea of Novel Security Issues.
The posts compare contractual liability under the SSCA with statutory liability under the PLD and argue that liability should fall on the party that can most easily avoid the costs when a defect was knowable or should have been knowable.
Regulatory countdown plus historical authority: Jeff Williams uses specific dates and obligations, then reaches back to the OWASP Secure Software Contract Annex and Novel Security Issues to frame the current debate.
Jeff Williams explicitly says it will be for courts to decide whether rogue AI behavior is a defect and says they do not know whether it qualifies.
For brands planning a campaign
A cybersecurity vendor selling liability-ready application security can use this as a compliance and legal-urgency theme.
A webinar or thought-leadership piece could pair Jeff Williams with a legal or risk voice to discuss PLD and CRA readiness, contract language, and what security teams need to prove about libraries, CVEs, and runtime exposure.
The content should preserve the open legal question about rogue AI rather than present a settled answer.
AI as both threat and solution in vulnerability discovery
Jeff Williams says the Mythos and Glasswing announcement should be a wake-up call.
Read more
The post argues that software stayed accidentally safe because vulnerability analysis was slow, using a coral reef and shark analogy: complexity made it hard for attackers to map pathways, but automated mapping tools will change that.
Jeff Williams expects attackers to get similar mapping capability and says the exposure window is collapsing.
They hope AI helps work through the vulnerability backlog over the next few years, but say that will take time, and recommend updating AppSec for a Dark Software Factory future and adding runtime security to the application layer in the meantime.
Extended analogy and scenario forecasting: the coral reef, sharks, and Google Maps image makes an abstract exposure-window argument concrete for a general reader.
For brands planning a campaign
This gives a vendor a vivid AI-security narrative that is not only about AI risk but also about runtime defense during the transition.
A webinar could ask what the Dark Software Factory means for enterprise AppSec programs and where runtime security fits while AI-assisted discovery and exploitation accelerate.
The campaign should keep both sides of the argument: AI as a threat accelerant and AI as a possible backlog-reduction tool.
Assurance-based secure development as the longer-term shift
In a post about Glasshouse shaking up penetrate-and-patch workflows, Jeff Williams says remediation is yesterday’s problem.
Read more
They argue the end state is using AI to streamline the security workflows that make up secure by design into a software factory that autonomously creates software from a spec and autonomously generates a compelling assurance case.
That case would identify threats, defenses to those threats, evidence that defenses are correct and effective, and runtime data showing security in production.
Jeff Williams says the shift from a negative, risk-management approach to a positive, assurance-based approach will take many years, not because the technology is absent but because people, process, and security culture resist change.
Contrast frame: negative hacking-ourselves-secure risk management versus positive assurance-based development, with an AI-generated assurance case as the endpoint.
For brands planning a campaign
A vendor positioning assurance-based development to enterprise buyers can use Jeff Williams as a forward-looking voice.
A thought-leadership collaboration could contrast risk management with assurance cases and ask what evidence enterprise buyers should demand.
The campaign should treat this as a multi-year industry shift, not a current product checklist.
Several posts promote Contrast CVE Shield as a free, fast-install tool.
Read more
Jeff Williams says it provides continuous runtime security without scanning, installs in minutes across Docker, Kubernetes, and Linux, and gives instant visibility across apps and APIs.
The tool is said to show all libraries present in runtime, which are in use, which CVEs are exposed, and which exposed CVEs have been attacked.
Jeff Williams says Java was released first, with other languages coming soon, and links to a free trial.
Demo-led product post: short benefit lists, a named demo from Dave, a performance number, and a direct free-trial call to action.
For brands planning a campaign
This is product-led developer content rather than pure thought leadership.
A vendor can evaluate Jeff Williams for a free-tool launch, a developer webinar, or a bottom-up adoption campaign.
The campaign should keep the specifics: CVE visibility, runtime detection, install targets, language roadmap, and no-scan positioning.
In the liability post, they ask what readers think about rogue AI as a defect and ask whether an AppSec and AI security program is ready to be liable for harms caused by defects. The post ends with the repeated line 76 days and Tick tick tick, which turns a legal deadline into a recurring audience prompt.
Question-led engagement: repeated direct questions and a countdown refrain invite comments and debate.
For brands planning a campaign
A webinar or thought-leadership collaboration can use Jeff Williams in a conversational, question-led format.
The questions give the audience a reason to respond and give the vendor a natural Q&A or community-discussion hook.
The campaign should let the unresolved legal questions stay unresolved rather than force a product answer.
Jeff Williams's saved posts promote application-security products, chiefly Contrast CVE Shield and ADR, with free-trial links and claims about runtime protection.
Read more
None of the posts state how Williams is connected to those products — whether as an employee, owner, or contractor — so the relationship is recorded as an undisclosed-role commercial relationship rather than employment or ownership. The posts also reference OWASP, where Williams says they wrote the Secure Software Contract Annex more than 20 years ago, and Anthropic, whose Mythos/Glasswing announcement Williams uses as a prompt to argue for runtime security.
Contrast CVE Shield
Disclosed partnership · 2026-09-11
Williams repeatedly promotes Contrast CVE Shield, a free runtime tool that lists libraries, flags exposed CVEs, and shows which have been attacked.
Read more
The posts ask readers to install it and carry sign-up links, but they do not say whether Williams works for, owns, or contracts with the vendor.
Williams markets ADR as runtime protection that sits inside running code, sees decoded data the way the application does, and keeps known vulnerabilities from being exploited.
Read more
Posts point to a free trial and describe ADR as the practical answer to WAF bypasses and collapsing exposure windows. The posts do not name the company behind ADR or state Williams's role in it.
Williams cites OWASP as the publisher of the Secure Software Contract Annex, which Williams says they wrote over 20 years ago, and draws a parallel between its treatment of unknowable "Novel Security Issues" and the EU Product Liability Directive's Development Risk Defense.
Read more
The post supports authorship of that document, not a current role at OWASP.
Williams discusses Anthropic's Mythos/Glasswing announcement as a turning point, arguing that automated vulnerability mapping will let attackers find paths that application complexity once hid, and that vendors will not be able to keep the capability contained.
Jeff Williams's posts are a running argument that software security has to shift from finding and fixing every vulnerability to protecting the application while it runs — and that legal deadlines are making that shift urgent.
Read more
A reader can follow the thread by starting with the runtime-protection and WAF posts, then the liability and Cyber Resilience Act countdowns, then the longer-range pieces about AI-assisted discovery and assurance-based development.
The work is short commentary and product demonstration, so it rewards readers who want a clear point of view more than deep technical case studies.
For similar thinking, compare Varun Badhwar on AI-generated code and vulnerability eradication, Renee Haas on exposure management and attack paths, and Tyler James Johnson on runtime control across data and systems.
Badhwar also writes about AI changing the pace of vulnerability discovery and about security teams that cannot keep up by fixing everything after the fact.
Read more
Badhwar's posts argue that AI-generated code and faster release cycles push more risk into production, and that security teams should measure how often new risk is introduced rather than only how quickly they clear old findings. That overlaps with Jeff Williams's argument that patching cannot keep pace and that protection has to move closer to the running application.
Badhwar frames the problem around preventive governance of AI-assisted development — intervening when an agent selects a vulnerable package or generates an insecure pattern — and around measuring both sides of the fix-versus-introduce equation. Jeff Williams puts more emphasis on runtime enforcement inside the application and on legal deadlines such as the EU Product Liability Directive and Cyber Resilience Act reporting duties.
Haas writes about the same overload problem Jeff Williams describes: security teams have more findings than they can act on, and knowing a vulnerability exists is not the same as knowing whether it is exploitable or important.
Read more
Both writers argue for prioritization based on real exposure rather than raw finding counts, and both connect technical risk to business impact.
Haas approaches this through exposure management and attack-path analysis across hybrid networks, asking whether a vulnerability is reachable and what it could affect.
Jeff Williams approaches it from the application runtime, arguing that web application firewalls cannot see decoded data and that runtime instrumentation can identify which exposed CVEs have actually been attacked.
Haas also writes authored articles and conference promotion, while Jeff Williams's retained posts are shorter commentary and product demonstration.
Johnson makes a parallel argument that AI has removed an old buffer in cybersecurity: attackers no longer need scarce expertise, exploitation speeds up, and organizations built around perimeter assumptions are exposed.
Read more
Both writers say the answer is not just more scanning but control at runtime, where data, identity, business logic, and execution paths actually meet.
Johnson develops the argument through data and AI governance, describing fragmentation across pipelines, dashboards, and models as a control problem that slows AI initiatives and hides risk.
Jeff Williams stays closer to application security practice, with WAF bypass examples, deserialization defenses, CVE visibility, and EU liability countdowns.
Johnson's Project Glasswing analysis is broader and more enterprise-architecture oriented.
For a cybersecurity vendor selling runtime application security and assurance-based development, Jeff Williams is a relevant topic-fit voice to evaluate, but the supplied evidence supports content appeal more than measured audience fit.
Read more
The seven LinkedIn posts are written for software producers, AppSec and AI security programs, and security leaders: selected examples include EU CRA vulnerability reporting, EU Product Liability Directive exposure, a PeopleSoft WAF bypass and deserialization attack, runtime protection for applications and APIs, AI-driven vulnerability discovery, and secure-by-design/assurance workflows.
That content is likely to appeal to practitioners and enterprise security buyers, yet the packet does not include an audience composition export, so it does not verify employer, occupation, job seniority, geography, age, or gender.
The profile snapshot shows 24,012 LinkedIn followers as of October 23, 2026, which is an account-size signal, not evidence that followers are enterprise buyers.
Before booking a webinar or thought-leadership collaboration, ask for recent results for comparable themes (runtime security, CVE exposure, software liability, AI security) in comparable formats, plus any audience survey or platform demographics export that shows professional attributes and geography.
The reviewed posts do not document a creator sponsorship program, sponsored-content rate card, media kit, or partnership intake.
Read more
They show Jeff Williams promoting Contrast runtime security products, especially free Contrast CVE Shield and ADR, with sign-up and demo links.
For a buyer planning a webinar or thought-leadership collaboration, that means there is no verified public sponsorship format to book.
Any partnership would need direct negotiation, and the buyer should confirm whether Jeff Williams is available for external vendor work, what disclosure would apply, and whether a collaboration can include product promotion beyond Contrast's own tools.
The posts also show a strong point of view on runtime protection, software liability, and assurance-based development, so a collaboration would fit best as a technical or opinion session rather than a generic sponsored placement.
A cybersecurity vendor selling runtime application security and assurance-based development to enterprise security buyers.
Read more
Decision: strong fit for a technical webinar or thought-leadership collaboration, not a generic sponsored placement.
The posts are built around the exact buyer problem this vendor sells against: patch fatigue, CVE exposure, and regulatory deadlines.
Jeff Williams shows the runtime visibility chain — libraries present, libraries in use, exposed CVEs, attacked CVEs — and argues runtime protection is a practical alternative to fixing every vulnerability.
The material also ties EU rules to operational need: the Product Liability Directive applying to software and AI on December 9, 2026, and the Cyber Resilience Act's 24-hour and 72-hour reporting duties.
The assurance-based development theme gives the collaboration a longer arc: moving from penetrate-and-patch toward a software factory that generates an assurance case with runtime data.
The strongest format is a co-presented technical session where Jeff Williams walks through a WAF bypass or a runtime CVE demo, then discusses what buyers should demand from an AppSec program.
This is a content and topic fit; it is not yet a measured audience fit, because no platform demographics export or comparable performance data was supplied.
When to choose a specialist
A WAF or perimeter-only security vendor seeking a sponsored placement.
Read more
Decision: poor fit.
Jeff Williams's posts directly argue that WAFs cannot reliably protect modern apps and APIs because of an impedance mismatch between what the WAF sees and what the code sees, and because request data is no longer simple name=value pairs but complex structures in multiple serialization formats.
A paid placement with a WAF vendor would put the creator in conflict with the central argument of their own content.
A second poor-fit brief: a general B2B SaaS or marketing audience with no security or compliance stake — the posts are technical, regulatory, and product-led, not broad-appeal marketing content.
The partnership evidence also shows no public sponsorship rate card, media kit, or intake route, so any paid placement would need direct negotiation and disclosure.
That does not mean collaboration is impossible; it means the collaboration should be a technical or opinion session with a compatible vendor, not a generic sponsored slot.
A worked campaign example
For the good-fit brief, a worked campaign angle is a 45-minute webinar titled around the CRA reporting clock and runtime evidence.
Opening: Jeff Williams sets the September 11 CRA reporting duties — early warning within 24 hours, detailed notification within 72 hours — and asks what a producer needs to know to respond.
Middle: a live runtime demo showing all libraries present in runtime, which are in use, which CVEs are exposed, and which exposed CVEs have been attacked, with the claimed under-20-nanosecond performance impact presented as a discussion point rather than an independently verified benchmark.
Then the Product Liability Directive countdown to December 9, 2026, and the open question of whether rogue AI behavior counts as a defect.
Close: a worked checklist of exactly what libraries are in production, where app and API CVEs are, which are exposed, which are attacked, and a contextual risk score for each CVE.
Deliverables: the recording, a one-page CRA evidence checklist, and a follow-up brief template.
Measurement: qualified enterprise AppSec registrations and brief requests, not follower count.
The vendor should disclose the collaboration and avoid presenting product claims or legal outcomes as settled facts.
This angle uses the runtime-protection and liability material already in the accepted topic and work sections, and it keeps the open legal question open.
Choose Varun Badhwar when the webinar or thought-leadership angle is upstream prevention and AI-code governance rather than runtime protection.
Read more
The posts argue for intervening at the moment an agent selects a vulnerable package or generates an insecure pattern, and for measuring how often new risk is introduced alongside how quickly existing risk is fixed.
A vendor selling secure coding, dependency vetting, or AI code-scanning would get a sharper fit here than from Jeff Williams, whose material starts after the code is running.
A Cybersecurity Awareness Month vulnerability-eradication session is the concrete format the posts support.
The posts do not show close reading of runtime exploit mechanics: no WAF bypass walkthrough and no runtime CVE exposure chain. The vendor trades Jeff Williams's runtime-protection and software-liability framing for a prevention-and-governance framing, and would need its own product material to supply the runtime half of the story.
Choose Renee Haas when the campaign decision is a buyer's guide to selecting an exposure-management or attack-path-analysis platform, or an event-based thought-leadership slot.
Read more
The posts write from inside a vendor partnership with RedSeal, Inc. and frame the buyer problem as too many findings and not enough clarity: reachability, attack paths, business-system impact, and whether a fix actually reduced risk. A vendor selling hybrid exposure management, risk prioritization, or attack-path analysis gets a more directly relevant collaboration than Jeff Williams offers, whose work is about protecting running applications and APIs.
The posts are more sponsored-article and event-promotion shaped than independent technical argument. The vendor trades Jeff Williams's detailed runtime discussion (libraries present, in use, exposed, attacked) for a prioritization and visualization framing, and would need to check whether a placement conflicts with the existing RedSeal relationship the posts disclose.
Choose Tyler James Johnson when the brief is about the control problem AI scale creates across data, identity, business logic, and execution paths rather than application CVE exposure.
Read more
One post argues most organizations have a control problem, not a data problem, and that real-time control across data and systems is what is missing between DataOps and AI scaling.
The other argues the perimeter security model assumes scarce attackers, slow attacks, and systems that can be reasoned about, none of which hold now.
A vendor selling runtime control, AI-era security architecture, or data-and-AI governance finds a closer fit here than with Jeff Williams's CVE-and-liability material.
The posts are more conceptual and less product-mechanical. The vendor trades Jeff Williams's specific runtime visibility chain and EU regulatory countdown for a broader control-and-architecture argument, and one of the two posts is about data and AI initiatives rather than security products, so the vendor would need to confirm the collaboration stays in the buyer's security lane.
This page draws on seven retained LinkedIn posts from Jeff Williams's account, observed October 23, 2026, covering runtime application security, CVE visibility, WAF bypasses, EU software liability and Cyber Resilience Act reporting duties, AI-assisted vulnerability discovery, and product demonstrations.
Each post was read in full; product-performance figures and predictions about legal and AI outcomes are recorded as the author's arguments, not verified facts.
The material is short commentary and product promotion rather than full articles, talks, or books.
No independent biography, publisher source, video transcript, or audience data was provided, so the authorship and wider significance of the OWASP Secure Software Contract Annex, Williams's working relationship to the products promoted, and any broader career history remain open gaps for a later research pass.
Recent engagement
Across their last 7 LinkedIn posts, the median post got 10 reactions and 1 comments. Checked 2026-11-02.
