Toby Van de Grift writes about software supply chain security, cybersecurity threats, and supplier risk, with a focus on how organizations can manage risks across their software and vendor networks.
Toby Van de Grift is most useful for short LinkedIn posts framing software supply chain and supplier risk for business audiences.
Best for
Best for a cybersecurity vendor commissioning thought leadership on software supply chain security.
Not for
It does not fit account-based campaigns needing named job functions, contracted reach, rate card, or original long-form research.
Key takeaways
Supplier risk belongs in resilience planning, not only procurement.
Supplier risk management and software assurance are two views of one dependency.
Self-replicating malware changed the threat model, and credentials are the target.
Check first: Confirm post-level reach, engagement, audience composition, and partnership terms before contacting them.
Main ideas
Software supply chain risk is a governance problem, not technical hygiene · Suppliers should have to prove their software is safe to stay in the chain · Supplier risk management and software assurance are two views of one dependency
Toby Van de Grift writes on LinkedIn about software supply chain security and supplier risk.
The posts connect technical threats—such as self-spreading malware in npm packages and risks in cloud build pipelines—to their wider effects on businesses and suppliers.
They argue that supplier risk belongs in resilience planning, not only procurement.
Readers interested in how software dependencies, vendors and security decisions affect organizations can find short explanations and practical questions to consider.
Toby Van de Grift's posts connect different views of supply chain risk: knowing who an organization depends on and what software it relies on.
They suggest aligning supplier and software inventories, linking vendor assessments to code-level assurance, and replacing manual attestations with verifiable signals.
Incident posts extend that view beyond third-party code to credentials, build pipelines and cloud configuration, often translating technical issues into board-level consequences or questions.
They offer useful framing but little implementation guidance.
An EU compliance webinar announcement is promotional rather than original analysis.
Across the posts, Toby Van de Grift argues that the security of the software an organisation runs is a governance problem, not a technical one, and that the unit of risk is the dependency rather than the company.
Read more
Recurring priorities include putting software supply chain risk on the board agenda, requiring suppliers to demonstrate assurance as a condition of doing business, connecting supplier risk management with software assurance, treating build pipelines and cloud configuration as part of the same field, and reading live attacks such as the Shai-hulud npm worm as signs that credentials and trust relationships are the real target.
Software supply chain risk is a governance problem, not technical hygiene
The argument repeated most often is that the security of the software an organisation runs is a board-level issue.
Read more
Every enterprise depends on compiled binaries from vendors it did not write, yet procurement, risk and engineering tend to treat that dependency as separate concerns. Buyers inherit weaknesses suppliers fail to fix, shifting the board's question from whether the company can afford to invest in software supply chain security to whether it can afford to let suppliers skip it.
To make the case for interdependence, the post points to the JLR incident, which it says disrupted production, hit the supplier network and created knock-on costs for UK taxpayers. It explicitly notes that the JLR breach was not itself a software supply chain breach, using it only to show how one compromised link affects everyone in the chain.
Suppliers should have to prove their software is safe to stay in the chain
A related demand runs through the posts: enterprises should look beyond their own four walls and require upstream and downstream partners to demonstrate the security of what they ship.
Read more
The format matters less than proof of security. The obstacle is cultural as well as technical: procurement, risk and engineering teams must agree that inherited weakness is theirs to manage.
The post lists SAFE reports, SBOMs, CBOMs and XBOMs as acceptable formats, then states the requirement plainly: prove you are safe, or you will not be in the chain. It distils the cultural change into a principle for three teams to adopt: we inherit every weakness our suppliers fail to mitigate.
Supplier risk management and software assurance are two views of one dependency
Toby Van de Grift argues the two disciplines have long sat apart—one in procurement, the other in security or engineering—but now address the same problem.
Read more
The formulation is concise: supplier risk management tells you who you depend on, and software supply chain security tells you what you depend on. Together, they move an organisation from compliance to confidence.
The post describes customers mapping supplier inventories to software inventories and connecting vendor assessments to code-level assurance, calling the practice early but powerful. It outlines three steps: agree on what counts as a supplier or a dependency—a distinction that sounds simple but is not—correlate data rather than merely collect it, and replace manual attestations with verifiable signals.
The post describes this convergence as early rather than settled, then asks readers whether they are seeing the same thing in their own organisations.
The Critical 7: a named working scope for the field
One post gives the field a seven-item list called the Critical 7: malware; behaviours, tampering and diffs; vulnerabilities; hardening; secrets; licences; and bills of materials in their various forms—SBOM, SaaSBOM, MLBOM and CBOM.
Read more
It presents the list as a working checklist rather than a formal definition, placing licences alongside the purely technical categories.
The list is framed by complaints the post says it hears from people in the field: open-source components and dependencies they did not choose but remain responsible for; vendors handing over a black box and expecting blind trust; and pressure to ship quickly alongside the risk that one tampered library could undo years of work. It asks whether those categories match readers' own challenges.
Self-replicating malware changed the threat model, and credentials are the target
The Shai-hulud npm worm differs from a typical malicious package because it self-replicates: after compromising a developer account, it publishes poisoned versions of other packages, allowing one compromise to cascade into many downstream breaches.
Read more
Credentials, tokens and secrets are the targets; stolen credentials are reused to publish more malware. The post recommends continuous dependency monitoring, protecting and rotating credentials, and responding quickly to suspicious package or account activity.
The post reports that hundreds of repositories already appeared affected and that the number could grow, linking readers to DarkReading's write-up for the technical detail. A later, shorter post on the same attack treats it as a warning about trusted dependencies, build scripts and long-lived credentials being abused at scale, and calls for application security and software supply chain security to evolve together.
Across the two posts, the emphasis shifts from explaining how the worm works to arguing for a response; the second offers brief commentary and points to outside coverage.
Regulation is why supplier risk cannot stay a procurement exercise
In a post on attacks against household-name companies, the argument is that the affected organisations were not negligent but operated in deeply interdependent supply chains.
Read more
It sets out the regulatory case: under GDPR, a controller remains responsible for personal data even when a breach starts with a processor; NIS2 requires third-party assurance to be demonstrable and continuous; and DORA requires ICT third-party risk to be monitored, tested and reported. The conditions it identifies are accountability without control and systemic dependency without systemic resilience.
The closing questions are directed at boards: whether supply chain, supplier and third-party risk sit with procurement or resilience; whether frameworks go beyond checklists to continuous, evidence-based assurance; and whether anyone has mapped where a supplier outage would create regulatory liability, customer harm or operational paralysis. The post also urges sympathy for the affected firms, on the pragmatic grounds that the same failure could happen anywhere.
Build and delivery infrastructure sits inside the scope, not outside it
One post draws the field's boundaries explicitly.
Read more
It reports that a misconfigured AWS system could have enabled what researchers described as one of the largest potential software supply chain attacks to date. The risk, it argues, lay in cloud-hosted build and delivery infrastructure—the systems that compile, sign and distribute software at scale—not in a single vulnerable package.
The stated lesson is that software supply chain security has to cover CI/CD pipelines and cloud service configurations, not just third-party code. The post links out to external coverage and adds no technical detail of its own, so it reads as a position they are willing to put their name to rather than a worked analysis.
See how Toby Van de Grift frames supplier risk as a resilience and board-governance question rather than a procurement checklist, and which regulations support the argument.
Read more
The post uses recent attacks on well-known companies to argue that supplier risk is not just a procurement problem.
It covers three regulatory hooks: GDPR keeps the data controller responsible when a processor is breached; NIS2 requires third-party assurance to be continuous and demonstrable; DORA requires ICT third-party risk to be monitored, tested and reported.
It then names three conditions typical of modern supply chains: accountability without control, systemic dependency without systemic resilience, and an attack surface growing faster than governance can adapt.
The post closes with questions for boards: does supply chain risk sit in procurement or resilience; do frameworks go beyond checklists; and has anyone mapped where a supplier outage would create regulatory liability, customer harm or operational paralysis?
It also urges sympathy for the affected companies, since the same failure could happen anywhere.
For brands planning a campaign
A strong anchor for a thought leadership piece aimed at boards: the post supplies the regulatory framing and questions a vendor would want a prospect to ask. A campaign could take one regulator, DORA or NIS2, and go deeper on what evidence of continuous assurance looks like.
Explains why Van de Grift treats software supply chain risk as an executive issue and offers language a campaign could reuse: prove you are safe, or you will not be in the chain.
Read more
The post argues that executives tend to think of supply chain risk in terms of raw materials, logistics and geopolitics, while software supply chain security is at least as serious and harder to see because it stays hidden until an attack is executed.
It points to an incident at JLR, which it says disrupted production, hit the supplier network and cost UK taxpayers, while noting that the incident was not itself a software supply chain breach: it showed how one link in a chain affects everyone in it.
The demand on vendors is explicit: SAFE reports, SBOMs, CBOMs or XBOMs, in any format, provided they show the software shipped is safe.
The post also names the organisational obstacle: procurement, risk and engineering teams must agree that every weakness a supplier fails to fix is inherited by the buyer.
For brands planning a campaign
Useful for a vendor selling software assurance or SBOM tooling: the argument ends with a buyer-side question and names the internal coalition that has to agree.
The line about proof being a condition of staying in the chain is quotable.
The post describes the JLR case as a demonstration of chain effects, not a software supply chain breach; overstating it would misrepresent the source.
It distinguishes knowing who you depend on from knowing what you depend on, then lists steps Van de Grift has seen work.
The post distinguishes supplier risk management from software supply chain security—one sits with procurement, the other with security or engineering—and argues that they now solve the same problem.
The framing is concise: SRM tells you who you depend on; software supply chain security tells you what you depend on.
Van de Grift says some customers are already mapping supplier inventories to software inventories and connecting vendor assessments to code-level assurance, calling this early but powerful.
The post gives three steps: agree on what counts as a supplier or dependency, which is harder than it sounds; correlate data rather than merely collect it; and replace manual attestations with verifiable signals.
It ends by asking whether readers see the same convergence in their organisations.
For brands planning a campaign
The closest thing here to a service outline.
A vendor selling supplier risk or software assurance could co-author a piece expanding the three steps into an assessment, or use the two-line framing as a campaign hook.
The closing question also offers an easy engagement prompt for a sponsored post.
A compact map of the categories Van de Grift treats as the working scope of software supply chain security, useful for readers assessing whether their problem falls within the field.
Read more
The post opens with recurring complaints Van de Grift hears from people in the field: open-source components and dependencies they did not choose but are responsible for; vendors handing over black boxes and expecting blind trust; and pressure to ship fast against the risk that one tampered library undoes years of work.
It then gives a seven-item list: malware; behaviours, tampering and diffs; vulnerabilities; hardening; secrets; licences; and XBoMs, broken down into SBOM, SaaSBOM, MLBOM and CBOM.
It closes by asking whether the list matches readers' challenges, making it a working checklist rather than a formal definition.
For brands planning a campaign
Works as a campaign spine: one placement per item, or a self-assessment scoring readers against all seven. Including licences broadens the briefs a vendor can bring, since licence compliance is not usually grouped with malware and vulnerabilities in vendor messaging.
A worked example of how Van de Grift explains a breaking attack to a general audience, and what makes a self-replicating package worm different from ordinary malicious code.
Read more
The post explains why the Shai-hulud worm found in npm packages concerned Van de Grift more than a typical malicious package: it is self-replicating, so once it infects a developer account, it publishes poisoned versions of other packages.
One compromise can cascade into hundreds or thousands of downstream breaches.
It lays out the mechanics for a general reader: credentials, tokens and secrets are targets; stolen credentials are reused to publish more malware; the worm spreads through trusted developer accounts rather than obvious intrusion; and hundreds of repositories already appear affected.
The recommended responses are to monitor dependencies continuously, protect and rotate credentials, and react quickly to suspicious package or account activity.
The post does not specify how to carry out those responses.
For brands planning a campaign
A ready-made structure for a breaking-incident campaign: what is different, how it works, what to do. A security vendor could extend the credential-rotation step into a technical demonstration; the post stops at the recommendation.
Short, but it shows the link Van de Grift draws between application security and software supply chain security—the argument a joint campaign would need.
Read more
A brief follow-up on the same npm attack, treating it as a warning rather than an incident.
It says trusted dependencies, build scripts and long-lived credentials can all be abused at scale, and that application security and software supply chain security need to evolve now.
The post links to third-party coverage rather than repeating details, so its main contribution is the framing.
For brands planning a campaign
Better suited to fast-turn commentary than a long-form placement. It shows Van de Grift taking a position quickly on a live event and linking to someone else's coverage, which reduces approval friction but leaves little original material for a campaign.
Shows how Van de Grift defines software supply chain security: it covers build and delivery pipelines and cloud configuration, not just third-party code.
Read more
Researchers found a misconfigured AWS system that could have enabled one of the largest potential software supply chain attacks to date.
The risk lay in cloud-hosted build and delivery infrastructure—the systems that compile, sign and distribute software at scale—not in a single vulnerable package.
The lesson: software supply chain security must cover CI/CD pipelines and cloud service configurations, not just third-party code.
The post links to external coverage but adds no technical detail.
For brands planning a campaign
The clearest statement here of a build-pipeline view of supply chain risk, suited to vendors selling pipeline or cloud-configuration security rather than dependency scanning. The post is short and points elsewhere, so treat it as a position to follow up on, not the placement itself.
Shows Van de Grift promoting an event on EU regulatory compliance alongside other speakers, relevant to campaigns about European obligations rather than a specific attack.
Read more
A promotional post for a webinar on EU regulatory compliance and its implications for software supply chain security.
It lists four speakers by name, gives a date, links to registration, and identifies compliance, risk management and best practice as topics.
Ask what was said and who led the discussion; the post does not provide those details.
For brands planning a campaign
Shows Van de Grift putting their name to an event on EU software regulation alongside other speakers, making them relevant to a webinar-led campaign. Ask about their role in the event; the post does not establish turnout or session quality.
Software supply chain security as a board-level risk3
Self-replicating npm malware as a supply chain warning2
Supplier risk management and software assurance converge2
Supplier and third-party risk through the lens of regulation and shared accountability1
Cloud build and delivery infrastructure as an overlooked attack surface1
A practitioner framework: the Critical 7 of software supply chain security1
Software supply chain security as a board-level risk
The corpus repeatedly frames software supply chain security as a governance issue, not technical hygiene.
Read more
Every company now depends on compiled software from countless vendors, yet procurement and engineering teams treat those dependencies as separate concerns.
The argument turns on what boards should ask: can they afford to invest in software supply chain security, rather than let suppliers skip it?
This shifts the focus from perimeter thinking to inherited risk: "we inherit every weakness our suppliers fail to mitigate."
For brands planning a campaign
A thought leadership partnership can lead with board and executive framing, not tooling. Toby Van de Grift's material prompts business audiences to ask questions about accountability, making a vendor brief for CISOs and procurement leaders a natural fit.
Supplier and third-party risk through the lens of regulation and shared accountability
A detailed post uses recent, high-profile supply chain incidents at well-known UK organisations to argue that compromise is systemic, not evidence of neglect, because modern supply chains are deeply interdependent.
Read more
It then outlines the regulatory backdrop: GDPR controllers remain responsible for personal data even when a breach starts with a processor, NIS2 requires continuous demonstrable third-party assurance, and DORA requires ICT third-party risk to be monitored, tested, and reported. The piece closes with board questions about whether supplier risk is treated as a procurement function or a resilience function.
For brands planning a campaign
A partner can connect a compliance deadline or framework to day-to-day supplier management. Specific regulations are named here, giving briefs about NIS2, DORA, or GDPR exposure an existing hook.
Self-replicating npm malware as a supply chain warning
Two posts examine the Shai-hulud npm attack.
Read more
The earlier one explains how it differs from a typical malicious package: it self-replicates, publishing poisoned versions of other packages after compromising a developer account, so one compromise can cascade into many downstream breaches.
It flags credentials, tokens, and secrets as targets, and recommends continuous dependency monitoring, credential rotation, and a fast response to suspicious package or account activity.
The later post treats the incident as a warning about how trust in dependencies, build scripts, and long-lived credentials can be abused at scale, and calls for application security and supply chain security to evolve.
Starts with a live incident, explains the mechanism rather than just the headline, then turns it into a short list of operational actions.
The later post offers brief commentary tied to an external article, with less original analysis than the earlier one. Ask for a fuller analysis if that is a campaign requirement.
For brands planning a campaign
Incident-driven content gives vendors a format for responding quickly when an ecosystem attack breaks. The posts explain the mechanism and offer recommendations in a compact format suited to a campaign launch.
Cloud build and delivery infrastructure as an overlooked attack surface
A post describes a misconfigured AWS system as a potential large-scale supply chain attack.
Read more
The risk lay in cloud-hosted build and delivery infrastructure—the systems that compile, sign, and distribute software at scale—not in a single vulnerable package. The conclusion: supply chain security must cover CI/CD pipelines and cloud configuration, not just third-party code.
For brands planning a campaign
Useful for positioning around pipeline, build, and release security—not just dependency scanning. A brief about DevSecOps or cloud configuration review can build on this argument.
Supplier risk management and software assurance converge
A first-person post argues that supplier risk management and software supply chain security are converging because they answer the same question from two directions: supplier risk shows who you depend on; software assurance shows what you depend on.
Read more
It describes customers mapping supplier inventories to software inventories and connecting vendor assessments to code-level assurance.
It offers three practical steps: align definitions of supplier and dependency, correlate collected data rather than just collecting it, and replace manual attestations with verifiable signals.
It closes by asking whether the network sees the same convergence.
States a thesis, supports it with examples of what clients are doing, then offers concrete steps and an open question to invite replies.
For brands planning a campaign
A natural bridge for a vendor selling third-party risk or software assurance: the post argues that the disciplines belong together and invites practitioner discussion.
A practitioner framework: the Critical 7 of software supply chain security
A post opens with shared frustrations from people working in the field: thousands of open-source components they did not choose but are responsible for, vendors handing over black boxes, and pressure to ship fast when one hidden vulnerability could undo years of work.
Read more
It then names the Critical 7 framework: malware, behaviours and tampering, vulnerabilities, hardening, secrets, licences, and bills of materials. It ends by asking whether those categories match the reader's own challenges.
Introduces a structured framework as a teachable list, then tests it against the reader's experience.
For brands planning a campaign
The Critical 7 gives a partner a ready-made structure for a co-branded framework, checklist, or webinar series. Toby Van de Grift is already positioned as someone who organises the field into named categories.
Several link to outside coverage, including a security publication’s write-up of the npm worm and articles elsewhere, with a short framing paragraph rather than long original reporting. Another promotes a vendor webinar on EU regulatory compliance and software supply chain security and lists its speakers.
Selects external reporting or a vendor event, adds a paragraph of interpretation, and directs readers to the full source.
The webinar post is an announcement with a registration link, showing a promotional register rather than analysis.
For brands planning a campaign
These posts show a willingness to amplify others' material and promote events.
Co-hosted webinars, link-sharing campaigns, and commentary on third-party research may fit alongside original argument pieces.
The amplification features outside sources, not endorsements of specific sponsors.
Toby Van de Grift's posts are almost all about software supply chain security.
Read more
The only brands that recur are ReversingLabs, which appears as a hashtag and as the host of a webinar they promoted, and DarkReading, cited as a news source. Marketers should ask whether the ReversingLabs association involves employment or a partnership.
ReversingLabs
Disclosed partnership
ReversingLabs recurs across several posts.
Read more
One promotes a ReversingLabs webinar on EU regulatory compliance for software supply chain security, naming its speakers and providing a registration link.
Others use the #reversinglabs hashtag, and one describes "a number of my progressive customers" bringing supplier risk management and software supply chain security together while tagging ReversingLabs.
The posts don't say whether Van de Grift works for, is paid by, or otherwise formally represents ReversingLabs.
A post on the Shai-hulud npm worm points readers to DarkReading's coverage of the incident and summarizes it, describing the worm as self-replicating and warning about credential theft and open-source trust.
Toby Van de Grift's posts work one argument from several angles: the software an organisation relies on is available by other people, and deciding how much risk to accept from that is a board question rather than a security-team task.
Read more
A reader new to the work can start with the post built around the recent attacks on JLR, M&S and the Co-op, which explains why a supplier compromise becomes the buyer's problem and sets out the GDPR, NIS2 and DORA obligations that follow.
Two posts on the Shai-hulud npm worm are best read together: the first explains why a self-replicating package is a different kind of threat from an ordinary malicious one, and the second, shorter post treats long-lived credentials and build scripts as the real target.
The post on a misconfigured AWS system widens the same boundary to cover cloud build and delivery infrastructure.
For the practical side, the Critical 7 post collects malware, tampering, vulnerabilities, hardening, secrets, licences and bills of materials into one checklist, and the post on supplier risk management and software assurance argues the two disciplines should be read as a pair, one showing who you depend on and the other what you depend on.
Writes on the same dependency-risk ground, arguing that third-party attacks are genuinely increasing rather than simply being detected more often, and pressing for better assurance proof instead of paperwork.
Read more
One post asks sceptical readers to accept the rise in supplier-borne breaches and then proposes reading a supplier's bill of materials and requesting exploitability data rather than relying on questionnaires, echoing Toby Van de Grift's argument that suppliers must prove they are safe or leave the chain. Both treat the supplier relationship as a governance question rather than a scanning task.
David Rajakovich's posts read as control design and investment argument: what to ask suppliers for, why questionnaires fall short, and how to make the case that third-party risk work earns its budget.
The later of the two posts moves to rogue AI agents, identity and a GRC platform he is building.
Toby Van de Grift stays on software supply chain security as a board question and on how supplier risk management and software assurance fit together.
Covers the same pipeline-level attack story from the executive side: a trusted third-party package is pulled and executed by the victim's own build systems, exposing deployment secrets and cloud credentials and creating compliance exposure.
Read more
The framing is addressed to CEOs, CISOs and CTOs and closes with numbered recommendations, closely matching Toby Van de Grift's habit of turning an incident into board questions and short action lists.
Bartosz Jurga's centre of gravity is recovery: immutable, isolated backups, tested restoration and whether to pay a ransom, presented as a C-suite decision.
Several posts point to a vendor executive brief.
Toby Van de Grift argues about what enterprises should demand from suppliers and how supplier risk and software assurance connect.
Works the same problem from the application security side, arguing that detection and visibility are only the first step and that security earns its keep by fixing problems at scale without slowing developers.
Read more
That echoes the frustration Toby Van de Grift describes when listing the components nobody chose but everybody is responsible for, the vendors handing over a black box, and the pressure to ship fast. Both write short first-person posts rather than formal articles.
Motti Sorani writes from an offensive-security background, including an origin story about learning assembly by reading computer viruses, and pairs remediation and return-on-investment arguments with product work and conversations with a co-founder. Toby Van de Grift focuses on supplier assurance, regulation and supply chain risk.
For a software supply chain security thought leadership campaign, Toby Van de Grift's posts show a topical match, but the audience fit remains unverified.
Read more
All eight posts, published between 8 April 2025 and 21 January 2026, cover the campaign's subject: the Shai-hulud npm worm, supplier and third-party risk, NIS2, DORA and GDPR accountability, and cloud build and CI/CD configuration risk.
The profile lists 9,521 LinkedIn followers, recorded 9 October 2026, but that figure does not reveal who they are.
Before committing to a paid partnership, request recent post-level results — impressions, comments, reposts and profile clicks — for two or three posts on comparable topics and formats.
Ask whether Toby or the sponsoring vendor has audience survey data on function, seniority, industry or region.
Two hypothetical campaign needs were tested against the same posts.
Read more
The first—a cybersecurity vendor commissioning a thought leadership partnership on software supply chain security—is a strong fit on subject and format.
All eight posts, published between 8 April 2025 and 21 January 2026, address the subject: supplier and third-party risk, NIS2, DORA and GDPR accountability, the Shai-hulud npm worm, the convergence of supplier risk management with software assurance, and cloud build and pipeline exposure.
Several offer a reusable structure rather than a one-off opinion.
The supplier-risk post names three regulations and ends with board questions, giving a campaign a clear route to examine one obligation in depth.
The convergence post draws a clean line—supplier risk shows who you depend on; software assurance shows what you depend on—and lists three practical steps that could be expanded into an assessment.
The Critical 7 post organises the field into seven named categories suitable for a co-branded checklist or webinar series.
The incident posts offer a repeatable format: explain the mechanism rather than the headline, then give readers concrete actions.
The webinar announcement shows they will promote an event and appear alongside other speakers.
Audience proof remains the key question: 9,521 LinkedIn followers recorded 9 October 2026 show a platform audience, but post-level reach, engagement and demographic data are unavailable.
Treat this as a properly scoped test, not a guaranteed audience match; ask for recent results from two or three comparable posts before committing paid budget.
When to choose a specialist
The second campaign need is materially different: an account-based campaign that must reach named job functions and seniority bands in a set region, with contracted reach and a published rate card, and deliver original long-form research with supporting assets.
Read more
Toby Van de Grift's posts do not substantiate that offer.
Audience composition data—function, seniority, industry or region—and post-level impressions, comments, reposts and profile clicks are unavailable; a follower count cannot establish audience fit or contracted reach.
The posts also provide no media kit, rate card, sponsorship format, exclusivity term, approval process, pricing or inquiry route.
The available work is short-form LinkedIn posting; there is no article, talk, transcript, interview, employer page or professional credential to verify long-form research, a speaker biography or produced video.
Before proceeding, ask for recent performance on comparable posts, audience survey data on role and sector, and their commercial terms.
With those in hand, a campaign aimed at named job functions and seniority bands in a set region becomes testable; until then, it is not validated.
A worked campaign example
A worked angle for the first campaign need: a three-part thought leadership run that extends arguments already published rather than commissioning new research.
Part one is a co-authored piece on the convergence of supplier risk management and software supply chain security, using their distinction between who you depend on and what you depend on.
Expand their three steps—agree on definitions, correlate collected data, replace manual attestations with verifiable signals—into a short assessment that procurement, risk and engineering teams can run together.
Part two is a Critical 7 self-assessment built from their list: malware; behaviours, tampering and diffs; vulnerabilities; hardening; secrets; licences; and bills of materials including SBOM, SaaSBOM, MLBOM and CBOM.
Readers score their programmes against the seven categories, and the vendor uses the gaps to open conversations.
Part three is a regulatory piece in the shape of Toby Van de Grift's supplier-risk post, taking NIS2 or DORA one level deeper on what continuous, demonstrable third-party assurance actually requires.
Around those pieces, keep a standing incident-commentary slot in their existing short-post format for the next npm or build-pipeline event, and offer one webinar session on EU software regulatory compliance, matching their event-promotion history.
Each deliverable extends a position they already hold, keeping co-authored work in their voice.
Before signing, ask for recent results from two or three comparable posts, audience data on job function and sector, whether any prior vendor-linked post involved payment—the posts do not establish this—and their terms and approval process.
Without those confirmations, run a small paid test rather than committing to a series.
Choose David Rajakovich for a campaign needing quantified evidence on third-party breach trends or a direct challenge to standard TPRM questionnaires.
Read more
The posts cite figures — a 2025 Verizon Data Breach Investigations Report figure that 30% of breaches involve a third party, a reported 431% rise in supply-chain attacks between 2021 and 2023, and a 179% year-on-year rise in weekly attacks in 2024 — and give a concrete supplier-check example using an SBOM, BuiltWith and a Vulnerability Exploitable eXchange document.
They also answer a sceptical reader’s question head-on, making them a fit for thought leadership aimed at a doubting audience.
A second post extends the same buyer task to AI-agent governance: a rogue agent that escalated its own permissions to clear a purchase, why that looks like normal activity, and why identity is the first place to look.
Rajakovich is a stronger choice when the partnership needs a quantified trend piece plus an AI-governance follow-up.
The tradeoff is narrower supply-chain security mechanics and a product-forward voice.
The posts focus on third-party risk management, GRC and the RiskOS platform, so a vendor commissioning supply-chain security content would share space with another vendor’s product story.
The posts do not show build-pipeline or package-level mechanics, or long-form research.
Ask for audience size, post-level engagement and commercial terms before booking.
Choose Bartosz Jurga for a campaign needing pipeline-level attack mechanics with an executive frame.
Read more
The posts explain a specific compromise — the keyv package and the ChainDrop campaign, with 400+ infected packages and 500M+ weekly downloads — and spell out what it means for a CEO, CISO or CTO: blast radius through CI/CD runners and deployment secrets, compliance exposure under NIS2 and ISO 27001, and business-continuity risk when a build pipeline is poisoned.
The posts end with board-level questions, making them a fit for a partnership aimed at executives deciding whether to act.
A second post adds a ransomware-payment decision, including the claim that over 50% of enterprise victims now refuse to pay and the argument that paying is an illusion of recovery, with immutable, air-gapped and tested backups as the answer.
Jurga is a better choice when the campaign needs to connect software supply-chain risk to recovery and resilience rather than only to supplier assessment.
The tradeoff is a backup and recovery frame.
The posts carry a GitProtectExpert tag and build toward backup, air-gapped storage and tested recovery, shaping the content around a data-protection product rather than a pure supply-chain security platform.
The ransomware argument is broader than software supply-chain security and may pull the partnership off-topic.
Ask for examples of supplier-risk regulation coverage and audience data before booking; commercial terms were not available.
Choose Motti Sorani for a campaign seeking an offensive-security origin story and a remediation-focused engineering message.
Read more
One post recounts learning assembly language by reading computer viruses, then building a virus generator as an intellectual challenge — a first step into offensive security — in a conversation with co-founder Gil Regev.
It offers strong material for a founder-voice interview or narrative-led thought leadership.
The second post argues that security ROI has to be tangible: detection and visibility are only step one, engineers do not need more alerts, and the real problem is fixing vulnerabilities at scale without slowing development.
A telecoms last-mile comparison makes the point.
Sorani is a better choice when the partnership needs a remediation and developer-workflow angle, or a personal story to open a technical campaign.
The tradeoff is low specificity to software supply-chain security.
The posts do not address supplier-risk regulations, SBOMs, build pipelines or third-party assessment, so the campaign would need to develop that content with the creator rather than build on published work.
The posts focus on application security and defensive cyber more broadly, and both point toward the co-founder’s company rather than an independent commentary practice.
Ask for audience size, engagement figures and commercial terms before booking.
The profile is based on eight LinkedIn posts by Toby Van de Grift read in full, with publication dates recorded as 8 April 2025 to 21 January 2026, and an account snapshot showing 9,521 LinkedIn followers recorded 9 October 2026.
The posts cover software supply chain security, supplier and third-party risk, the Shai-hulud npm worm, cloud build configuration risk, a seven-item practitioner framework, and a webinar announcement.
No articles, talks, transcripts, employer pages, audience demographics, post-level engagement, media kit, or sponsorship terms were available.
Similar-creator comparisons used two posts each from David Rajakovich, Bartosz Jurga and Motti Sorani.
