FAQ

The Cyber Toolchain is a tooling-first cybersecurity newsletter, with a show coming soon, for people who care how security products are used, built, adopted, and improved. Every day it covers what more than 1,300 open-source and commercial cyber tools shipped, and it writes up the features that matter along with the commands to run them. That count covers tools and hardware. We focus on the work in the trenches, meaning how the tools that protect organizations are built and used, instead of high-level talking points and vendor promises.

A toolchain is the tools you connect to get a job done, each one handing its work to the next. Your stack is every tool that you use. Your toolchains are the tools you actually run on each job and how they connect: the scanner feeds the SIEM, the SIEM alerts the analyst, and the EDR isolates the host. Because the tools connect, when one tool changes, every chain that runs through it can change. That's why we follow what each tool ships, so you can keep up with the tools you run. The full definition, with the diagram, is on What is a toolchain?.

The AI Toolchain is this project's sibling site, and it tracks AI tools the same way this one tracks cyber tools, with release notes, features, and usage examples so you don't have to scan them yourself. You can sign in to either site with the same email, and the AI Toolchain add-on gives one subscription access to both. We keep them as two publications on purpose so neither turns into one generic tech newsletter, and each one only covers its own tools. The AI Toolchain is newer and still building out its coverage, which is how this one grew too.

Because keeping up with cyber tooling is a full-time job nobody has time for. Release notes are scattered across hundreds of repos, changelogs, and vendor docs sites, and most of what's in them is routine bug fixes, so the genuinely useful new capability gets buried. We read all of it every day so you don't have to, and we tell you what changed and how to use it.

Audio has the same gap. There are plenty of great cyber shows, like Risky Business for news, Defense in Depth for industry topics, Inside the Network for the business side, and No Password Required for practitioner personalities, and I listen to all of them. But none of them focuses on the tooling and products used to defend organizations, and that boots-on-the-ground work gets overlooked in favor of high-level talking points without much practical context you can take back and apply. I want to help fill that gap.

You'll mostly get technical coverage of the latest open-source and commercial tools, their features, and the problems they solve. Here's what that looks like.

• A daily newsletter on what shipped, with the new features explained and real usage examples, plus a weekly highlights edition and a weekly product-docs edition. When a command has recorded output, open View command output under the example on the website. Emails link to that output and keep the command examples in the message.
• A page per tool with its release history, activity, licensing, and recorded command runs you can read the real output of, plus the screenshots and demo videos from its release notes.
• Video demonstrations of tools and their use-cases, and conversations with the people who build them, on a show that is coming soon.
• How tools work under the hood — the underlying technology and how they're deployed.
• How to build your own tools and prototypes through vibecoding and agentic engineering.

Several things are changing at once, and they all raise the stakes on the tools you choose.

• AI is changing attacks. Vulnerabilities that once took weeks or months to find and exploit now surface faster, phishing no longer takes native language skills, malware no longer takes deep OS-internals expertise, and voice and video deepfakes have opened a new kind of impersonation attack.
• Agentic engineering with AI coding agents makes it far easier for vendors, developers, and attackers to build cyber tooling.
• Regulation is increasing as the cost of cybercrime is predicted to reach $10.5T globally and AI adoption outpaces governance, which may leave us with the largest attack surface of my lifetime.
• Investment in cyber companies has climbed back toward 2021 levels.
• Budgets are tight, and most organizations are doing more with less, so they need more value from the tools they already have.

On a personal note, agentic tooling finally gives me the capacity to run a daily newsletter and a show alongside a full-time job, which I couldn't have done before.

The Cyber Toolchain is for people who care about how cybersecurity products are used, built, adopted, and improved. It's for:

• Practitioners who want to discover new tools and features and learn how to use them on real security problems.
• Security leaders who want a practical view of where tooling is headed and what their buying options are.
• Product managers and leaders who care about building better cyber products.
• VCs and advisors looking for emerging categories, technical founders, and product signals in cybersecurity.
• Open-source maintainers building useful tools who want to share their work with the security community.
• Startup founders who want to showcase their tools and learn from other builders navigating product, GTM, funding, and customer adoption.

This is a one-person team (with a full-time job), so I need help from the cyber community to move it forward. Here's where you can help.

• Recommend tools, FOSS or commercial, and use cases worth covering, including tools you understand the least but would like to learn about.
• Share redacted demo videos of the tools you use and the problems you're solving with them. Let's crowdsource this.
• Make introductions to startups and maintainers you think would be valuable additions to future episodes.
• Give honest feedback on the newsletter and the show, including what sucks, what's great, and how to make it better.

The feedback form makes it easy to send any of this, and the more context you include, along with contact info if you'd like me to follow up, the better.

If you're a FOSS maintainer, or a Seed or Series A cyber startup with users and a solid product you can discuss and demo across your top three use-cases, I'd be interested in having you on. Reach out by email or through the feedback form. If you're Series B or later, see sponsorship below.

Sponsors keep a show alive and growing, and we're glad to have them. Sponsorship here isn't a traditional ad slot because we want to keep the show ad-free as best we can. Instead, a sponsor gets a dedicated episode where the audience learns about your tools and use cases and sees a recorded demo, produced like any other tooling episode so it stays true to what the show is for. Sponsorship is for companies Series B and up; we'll happily have Seed and Series A startups on without it. For a different kind of sponsorship, reach out by email or via the feedback form.

More than you'd think. Building the software behind the site has taken over $10,000 so far, covering the pipeline that watches more than 1,300 tools and hardware devices, the newsletters, the tool pages, the analytics, and the sandbox that records real command runs. It also costs money every day it runs, for hosting, storage for every release note and documentation page we read, and the compute behind the summaries and analysis. None of that is covered by ads, so I pay for it out of pocket.

If this is useful to you, there are two ways to keep it going. The first is a subscription, which you can start yourself on the plans page. The second is sponsorship, a dedicated episode rather than an ad slot. See How can I sponsor? above, and reach out by email or through the feedback form to arrange one.

The Cyber Toolchain is created and hosted by Jon Schipp. It is operated by Cyber Toolchain LLC. See the About page for the full story.

Six, each a separate series with its own numbering. Five are named for what they do to the stream of releases, tail, grep, head, diff, and uniq, and the sixth, ls, lists what is new on the Toolchain, covering improvements to the site and the tools that arrived. The ISSUE dropdown on any issue page jumps between them, listing the five most recent issues of each; the archive has every issue ever published.

• Tail is the daily release firehose. Every day, at a steady time each morning, it covers everything that shipped across the watchlist and the features each release brings, with runnable commands where they help. The email leads with five to ten releases we picked, more on a day with more worth reading. Every release is in the issue on the web. A quiet day publishes nothing rather than padding an issue, and it's free to read on the site.
• Grep is Tail narrowed to only the tools you run. You pick tools and categories and, from Researcher up, keywords, which match whole words in the summaries, feature bullets, breaking changes, and Coverage titles and targets we publish, so one Grep can follow "SCIM" or "eBPF" across every vendor. You can hold several, each with its own name, list, and email, so one can cover the stack you run and another the vendors you're watching. A Grep has no fixed schedule on purpose, because most days are empty when you filter to one person's stack, so it arrives when its tools ship and stays quiet otherwise. It rides the daily, so on a day it has something it shares that steady morning time. The free plan holds one Grep of up to three tools, releases only. Practitioner holds three Greps per site, Researcher holds five, and Business is unlimited. Grep is delivered by email only, with no web edition.
• Head is the week's top picks, on Fridays, usually by 17:00 UTC. It's our chosen highlights from everything that shipped, each with a short "why it matters". It has five picks, and Practitioner and above can switch it to ten. Each issue also shows the week in numbers, with charts for the past twelve weeks. Click a number to browse the week's changes, tools, product launches or breaking changes, and filter by tool. The week page includes docs and API changes carried in the daily issues. Free to read on the site, and delivered free with no card.
• ls (New on the Toolchain) arrives on Mondays with improvements to the Toolchain itself, including screenshots and examples where available, followed by the new cyber tools. It covers every tool we started watching that week, with what it does, how long it has been alive, and the three we would try first. Press Add to Grep to choose an existing Grep or create a new one, then review and save. While signed out, the tool is saved automatically to My Toolchain in this browser, and we'll sync it to your account the next time you sign in. Use Import from My Toolchain in a Grep editor to add saved tools to email updates. If there are no improvements or new tools, no issue ships. Free to read on the site, and delivered free on every plan.
• Diff covers what vendors changed and didn't announce, on Wednesdays, usually by 16:30 UTC. You see changes to the product documentation and API reference pages of the tools we watch, from new capabilities, settings, endpoints and changed behavior to wording fixes and individual character changes. It's subscription only, and the newsletter page carries one sample entry.
• Uniq shows how vendors reposition, reprice, rebrand, and change hands, monthly. You see the category a vendor claims, the buyer they name, how they package what they sell (which plans exist, what each one now includes, and what it costs), and the language the whole market is picking up or dropping, counted across the cohort, because one vendor rewording its hero is a data point and nine doing it in the same quarter is the market moving. You also get every acquisition and partnership those vendors announce, with a short summary of each and how it compares with the deals of the past year. Included with Researcher and Business, and delivered by email only. Your back issues are listed on your account page.

Yes. Subscriber issues includes the latest shared edition published before you joined for each newsletter your plan can read, plus editions published since you joined. The starter edition keeps its original date and remains in your list while your plan includes it. This does not resend old emails or create personalized Grep or Uniq reports. If no edition has been published yet, the next published issue will appear here.

Yes. Every public weekly Head issue offers PDF and EPUB downloads for its five free picks. EPUB works with Apple Books, Kobo, Calibre, and Amazon's Send to Kindle service. Use the download actions at the top of any Head issue.

Yes. Entitled Diff, extended Head, and Uniq issues offer PDF and EPUB downloads in the Subscriber issues section of your /account page. Each delivered Grep Report also keeps its selected month or quarter as a private HTML page with HTML, PDF, and EPUB controls. EPUB works with Send to Kindle, Apple Books, Kobo, and Calibre. These downloads use the same private, unguessable links as the subscriber web editions, so please do not share them.

Every Tail and Head issue is free to read, with no account, and so are the tools directory and many of the charts on the analytics page. Paid plans add daily delivery, broader Grep filtering, the methodology behind every figure, and additional charts, data signals and analytics that only paid plans can see, including observed maintenance activity, published fix topics and recorded company events. Some chart labels are held back on the free tier; see Why are some chart labels hidden? below. On top of that, the free plan delivers two newsletters and one Grep:

• Free — $0, no card. Head lands in your inbox every Friday with our chosen top picks from the week, and New on the Toolchain brings Toolchain improvements and the tools that arrived. One Grep follows up to three tools and emails you their new releases when they ship. Unsubscribe from any issue.
• Practitioner — $10/month, or $100/year — a 17% saving. Adds Tail daily, Diff weekly, and three Greps per site — the same coverage narrowed to the tools and categories you actually run, so you stop scanning a 100-release firehose for the six things you care about. Track as many tools as you like, and read Head ten picks deep instead of five.
• Researcher — $20/month, or $200/year — a 17% saving. For questions bigger than one issue. Read the analytics we publish nowhere else, including fix-bullet categories, concentration and recurrence, with observed coverage and uncertainty beside each chart. Alongside that: query everything we track from your own scripts and agents over an API and MCP server. Proactive notifications of new findings are coming soon. It also adds Uniq — how the vendors we watch reposition themselves, monthly, each tool's standing among its peers on its score card, and every tracked vendor's pricing and packaging history.
• Business — $1,000/month, or $10,000/year. Everything in Researcher with no Grep cap and a quarterly leadership report: a page and PDF covering measured peer rankings, vendor filings, pricing and category activity. Coverage depends on the sources and history available for your category. See plans for current purchase availability.

Four things are the exception to "free to read": Grep exists only as delivered email, because a per-subscriber filter has no meaningful web page; Uniq is for subscribers, delivered by email and readable on this site, with your issues listed on your account page; Diff is subscription-only with a single sample entry shown on the newsletter page; and the analytics charts that rank individual tools show everyone the shape and the numbers but not the names.

Once a month you get what changed at the vendors behind the tools on your watchlist. Each finding shows the dated sources it rests on, what it means for you and what to check next, with a chart and a table of the numbers where they help. Every paid plan includes this part. Researcher and Business also get the full issue, with findings across the vendors we reviewed that month.

• It follows your watchlist. The tools and categories you follow on your account page decide what you see. Watching a tool doesn't mean you use it. It is simply what you asked us to follow.
• A quiet month says so. If nothing qualifying changed, you get a short note instead of a padded issue. If we could not finish checking some of your tools, the note names them, so a gap never reads as "nothing happened".
• You can check every finding. Each one links the sources it was written from, with their dates. A finding that fails our automated checks is left out.
• You choose. Switch Uniq on or off from your account page, like any other newsletter. Your email carries up to five findings per section, and your account page shows the rest.

No — it's the design. Each Grep is a complete issue on its own, so you can forward one to a colleague or route it to a team channel without it having holes where the overlapping entries would be. A release that matches two of your lists appears in both. Every card in a Grep — in the email and in the preview — carries the reason it's there ("matched: cloud-security", 'matched: "scim" · feature bullets'), so you can see where the overlap comes from and narrow one of the two lists if you'd rather see each release once.

Most likely it's too narrow. Open it on your account and choose See an issue — the day strip shows how often it would have fired over the last month, and names the category that would fix it if the answer is "almost never". Two other causes worth ruling out: a tool you follow may have been renamed, which the account page flags on the Grep itself, and a paused Grep sends nothing while it's paused. A Grep with nothing to report sends no issue at all rather than an empty one, so quiet days are silence by design.

Yes, on any plan including the free one. Send me a test on your account puts a real issue in your inbox on demand, rendered in whichever palette you picked — the same renderer that produces the real thing, so what you see is what will arrive. It sends the Head edition you read, five picks or ten, and the picker beside the button offers the other one if you want to compare before choosing. Any plan can also preview a Grep on the site, built from that Grep's own settings against the last month of releases.

Yes. Tick I'm taking a break on your account and every newsletter stops, including the paid ones — your selections are kept, so unticking it starts them again on their normal schedule with nothing to set up. A subscription keeps running while you are paused; a break is about what arrives, not what you pay for, so cancel instead if that is what you want. Switching every newsletter off individually does the same thing to your inbox, with one difference: an account that has gone silent that way gets a note once a quarter asking whether it was meant. A declared break gets no note at all.

Tail every day, at a steady time each morning. Grep rides the daily, so on a day your tools ship it shares that time. If either arrives late, its email opens with a delay notice. Head on Fridays, usually by 17:00 UTC. New on the Toolchain on Mondays; it is new, so there is no measured arrival time to give yet. Diff on Wednesdays, usually by 16:30 UTC. Uniq on the 8th of each month, usually by 14:47 UTC.

Tail and Grep arrive at the same time each morning all year. Delivery depends on how many sources answered and how much they shipped. The other weekly times above are measured from recent runs and rounded up, so most issues arrive earlier. Tail and Grep send nothing on a quiet day rather than padding an issue — silence is a real outcome, not a delay.

Each week the releases from that week are compared against each other and at most ten are picked. Each release is graded from 1 to 5 on three things, weighted equally: depth (a substantial capability, not a minor flag), impact (how much it changes what you can do) and novelty (whether any other tool did it first). For novelty we check each capability against the history of every tool we track, so a feature most tools already have earns nothing and the first tool to do something earns the most. The published issue and the free email carry the top five; a Practitioner plan or above can switch Head to ten on the account page and read the same week five tools deeper. The bar does not drop for the second half — most weeks fewer than ten clear it, and the issue says so. A tool featured one week is held out of the next one, however much it ships — the shortlist is there to widen what you see, not to track the loudest vendors week after week. If nothing clears the bar in a given week, no issue ships and the series doesn't burn a number on a filler edition. The picking is done by an LLM — see Is this AI-generated? below.

On the 1st of each month you get one top pick: the single product that shipped the most over the month that just ended. We choose it by comparing that month's weekly Head picks against each other, so it is always a product that already made Head. It is one product, never a vendor. You get the story of what it changed and why it won, rather than a score, and then a few examples of what it shipped. When a quarter ends, the same mail also names the pick for the quarter. A month with fewer than two Head issues has no pick. Top picks are free to read, and they are mailed to everyone who gets Head. It is its own mail, separate from the Friday issue. Every past pick is at /newsletter/top.

Yes. On a Head issue, the "SHARE THIS WEEK" buttons download a ready-to-post PNG of that week's picks — Top 5 gives a square image of the week's five highlights for a feed post, Top Pick a portrait image of the single standout for a story, both branded and sized for social. The home page's Top Picks section carries the same two buttons for the week, and Square and Portrait buttons on the monthly and quarterly pick cards, each downloading that pick's own card. On the tools page, open any tool and use the ▽ share button in the modal to download a card for that single tool — its category, version, GitHub stars, release count, and a 12-month release-cadence chart. The images are rendered in your browser; nothing is uploaded. To point someone at a specific tool in an issue, use the ⧉ Share button next to that tool's name in the newsletter or highlights — it copies a direct link to that entry (on a phone it opens your share sheet instead).

For Head, yes at the same edition — five picks by default, or ten if you have switched Head to ten picks on the account page, in which case the email carries all ten and links to a private page with them. For Tail, yes — the same releases, delivered rather than read.

What a subscription buys is delivery and filtering: Tail in your inbox, Grep narrowed to your tools, and the documentation and API changes vendors made without announcing them, collected into Diff on Wednesdays.

Every Diff issue opens with the week's numbers. We count each documentation and API change we detected on the watchlist in the 7 days the issue covers. A change counts as announced when the same tool's release notes, changelog or a launch we track already covered it, looking back 30 days before that week, since vendors often announce first and update the docs later. The share is the changes left over after removing those, divided by everything we detected. Announced changes are left out of Diff and stay in Tail. The count only covers sources we track, so "not announced" means not announced anywhere we watch, not that a vendor never said it anywhere. If a number looks wrong, tell us on the feedback page.

It watches the official product documentation of the tools on the watchlist — not just the front page, but the tree of feature and product pages beneath it — and their API reference pages, where a new endpoint, a renamed parameter or a retired field shows up before your integration breaks. It surfaces what's newly added: brand-new pages the vendor just published, plus new capabilities, settings, endpoints and changed behavior within existing pages. It deliberately does not report:

• Anything the vendor already announced. Releases, changelogs and launches are Tail's. A doc change that only restates an announcement Tail printed for the same tool in the last month is left out, so Diff holds just what changed without being announced.
• Wording, grammar, and formatting edits. Only added content that describes what the product now does is worth an entry.

Docs changes are a leading indicator: capabilities often land in the docs before they're announced anywhere else.

By what kind of change a vendor made, not by how much they wrote about it: behavior changes first, then API surface changes, then removals and deprecations, then everything else. The three that carry weight:

• Behavior changes — the vendor's own documentation says something that already works today will work differently (breaking_changes). Named at the top of the issue, with a link to the full list.
• API surface changes — an endpoint, a parameter or a field moved in a machine-readable spec (api_diff). This is the change that breaks a script without anyone reading prose.
• Removals and deprecations — the vendor's own prose says something is gone: deprecated, end-of-life, replaced, or renamed.

Everything else follows, ordered by how completely the change is described. A quarter to a third of the tools in a typical issue carry one of those three; the rest are ordinary documentation edits. The email carries a fixed number of tools — some in full, the rest as a short summary of what changed — and names the ones it held back, with a link to the complete issue: nothing is cut from the issue on the site. Whether any of it matters to the stack you run is a question this order cannot answer: that's what Grep is for, and adding a tool to your watchlist means it is never held back from you again.

When a vendor changes a documentation page, we compare it against the last version we read and show you the changed text itself — the lines added and the lines removed, in place. The removals are often the part worth seeing: a retired option, a lowered limit, a default that quietly moved. Every subscribed plan gets the changed text itself inside the delivered issue, not a description of it. The same applies to API changes, where we show the before and after of the endpoints that moved — the parameters, their types, whether they became required, and the response codes that appeared or disappeared.

Long changes are trimmed to keep an issue under the size limit mail clients impose, and the issue says how many were shown in full and links the page for the rest.

Subscribe by email from the homepage — the signup is at the bottom. Head is free and needs no card, and so is one small Grep; the paid plans add Tail, wider Greps, Diff and Uniq on the tools you watch, and Researcher adds the full Uniq. Every paid plan can also read each issue as a persona edition, narrowed to what your role acts on, and choose how much of it you get: the 10 tools that matter most, your role's full edition, or the whole issue, as headlines or in full. If you'd rather use a reader, the Feeds page lists everything you can follow: the combined RSS feed at /rss.xml (Tail + Head), a separate RSS feed for each series on its own (/newsletter/releases.xml, /newsletter/highlights.xml, /newsletter/docs.xml), one feed per tool category, and per-tool feeds. Diff is deliberately kept off the combined feed — it tracks documentation changes rather than releases, so it would drown out the release items — but it has its own feed if you want it. The Feeds page is under Developers in the menu on the left, or search for it (⌘K) by typing "feeds", "rss", or "subscribe".

Every subscriber has a share link on the account page — anyone signed up gets one, including a free Head reader. Send it to a colleague and their first month is free (pick yearly and it's the equivalent taken off their first year instead). Once their first real charge lands you earn two months of your own plan, and a third when their second charge lands — three at once if they went yearly. A free reader earns complimentary Practitioner months rather than months of a plan they don't have. Referred months are capped at 12 a year while the program runs, Business plans don't take part on either side, and a self-referral or someone already subscribed doesn't count toward anything. The account page shows how many friends joined and converted and how many months you've earned — never who they are. One link works whether your friend signs up here or on The AI Toolchain.

A busy day can carry seventy-odd cyber tools, and a flat list of seventy tells you nothing about which ones to read first. Each issue ranks its tools on how completely their releases are documented — how much a note explains, whether it names real flags, endpoints and config keys, whether there is a command you can run, a screenshot, or a breaking change — and gives the top few the full write-up, the next tier the headline and a summary, and the rest a one-line entry.

You can check any of it. Every tool carries a tier marker beside its name — hover or tap it and it shows that tool's own arithmetic, the feature scores and the bonuses that produced its place. Paid plans can read how the ranking works on the methodology page. Briefed goes further and reads the day down to its notable changes — at most a quarter of the issue: the new capabilities, breaking changes and deprecations a practitioner would act on, picked from the whole issue whichever tool shipped them, and tools with nothing notable today are left out. Nothing is removed either way — the Everything button at the top of any issue opens every tool at full detail, your choice is remembered, and the issue on the site carries all of it regardless. The control is labelled INFORMATION DENSITY and sits in the VIEW console beside the reading dial, on the weekly picks as well as the daily — there it keeps only the features each tool was picked for, without ever dropping a pick.

A short editorial read on what shipped that day and why it matters — written from the same release notes the entries below are, and grouped into two to four outcomes rather than a list of vendors. Each outcome is tagged with the part of security work it advances, using the NIST Cybersecurity Framework's own vocabulary: govern, identify, protect, detect, respond, recover.

It says what a team can now do that it could not yesterday, not what a vendor built. Most days have no single theme, and it says so rather than inventing one.

Two different models write the summary at the top of an issue, and we have not decided which reads better. Rather than guess, the page shows both and asks — the A/B switch is the same issue summarised twice, and the thumbs record which one you preferred. On Head, the switch also re-orders the week's picks by each model's own ranking; it never changes which picks they are.

The versions are deliberately unlabelled. If we named the models, the vote would measure what you think of the names rather than what you think of the writing. Votes are anonymous and carry nothing about you or your account.

Yes — add ?filter=breaking to any issue URL and the page shows every tool that shipped a breaking change, at full detail, whatever position it ranked into. Breaking changes are not lifted to the top of an issue by default: they read best inside the tool's own section, under the summary that explains what else changed with them.

If you have saved tools, the On your toolchain section at the top flags any of yours that broke something and links straight to it. That is the one place we know you run the tool, which is what makes the flag worth more than the noise it would be everywhere else.

Open your account and choose Manage billing. For your security it may email you a fresh sign-in link first. Then Paddle's billing page opens in a new tab, and you cancel there. Your plan keeps running until the end of the period you have already paid for, and you are not charged again after that. Cancelling does not delete your account. It moves you to the free plan when the period ends.

Ask within 30 days of a charge and you get all of it back, with no questions. Email info@cybertoolchain.io from the address you subscribed with, or ask Paddle at paddle.net. Paddle sends the money back to the payment method you paid with. A refund ends your access to the paid plan when it is issued. The refund policy covers what happens after 30 days.

Open your account and choose Manage billing. It opens Paddle's billing page in a new tab, where you can update your card, download invoices and receipts, and cancel. Paddle is our merchant of record, so it sends the receipts and takes the payments.

Yes. Open your account and choose Run setup again, next to Save. If you stopped partway, you can continue where you left off or start over; your current settings are filled in either way. Each step saves as you go, and everything it sets you can also change on the account page directly.

If a link says it has expired, ask for a new one on your account page. Each link works once and lasts from 15 minutes to 3 days, depending on the email, so an old email or a second click will show that message. Nothing is wrong with your subscription. Open the newest link you were sent.

There is no control for it on the site. Email info@cybertoolchain.io from your current address and tell us the address you want instead. We will help you move over.

Sign in at My account, choose Delete account, then choose both Cyber Toolchain and AI Toolchain, or this site only. Read the warning and confirm; we may ask you to verify your email again. Deletion cannot be undone. We stop the selected newsletters, remove the selected account data and cancel its subscriptions. A paid plan shared by both sites is cancelled even if you keep the other account; a separate plan for the other site stays. If you keep the other site, it sends only the newsletters you turned on there. We send a final confirmation email, and you can no longer sign in to the deleted account. Deletion does not automatically issue a refund. Paddle keeps billing records required by law. The privacy policy explains shared data and retained security records. Email us if you cannot sign in.

Soon. Webhooks are coming to Researcher and Business. You give us an HTTPS address on your account page, and we send it a signed request when a tool you follow ships, so a chat channel, a ticket queue or your own service can react without anyone reading the newsletter first. You pick all tools, some tools or some categories.

• One address per site. Send a test before you turn it on, so you know your end works.
• Check every request is from us. Each one carries webhook-id, webhook-timestamp and webhook-signature headers, in the Standard Webhooks format. Sign id.timestamp.body with HMAC-SHA256, using the part of your secret after whsec_ decoded from base64, and compare it with each value after v1,. Refuse a timestamp more than five minutes old.
• We retry for about a day. A request your end doesn't answer with a 2xx is tried again with a growing wait. The webhook-id stays the same on every try, so you can drop a duplicate.
• Rotating your secret doesn't break anything. The old one keeps working for 24 hours while you switch over. We show a secret once, so save it when you see it.

We only send to public HTTPS addresses on port 443. Your account page shows the last 30 days of requests, and you can resend one that failed.

Email info@cybertoolchain.io or use the feedback form. We reply within two business days. Say which address your account is under, so we can find it. We never ask for your card number or a password.

The Tools page is the full watchlist — every tool being monitored, not just the ones that shipped something recently. You will find tools and hardware in it. It's the place to browse the landscape rather than the news.

• The chart at the top shows how much the watchlist shipped, one bar per week for the last year. Hover a bar to see that week's releases and how many tools shipped. The cards under it compare the latest full week with the four before it, and show how the watchlist has grown.
• The search box above the table searches everything at once — tool name, vendor, category, source and description. Type kubernetes to find every tool that works on it, whichever column says so. Several words narrow rather than widen. It combines with the column filters below.
• Every filter lives on the column it filters. Click a heading to filter by it — click TOOL and type rapid7 to see only Rapid7's products, click CATEGORY and pick from the list, click LICENSE for open-source or commercial. Filters combine, and each shows as a chip you can click to remove.
• The arrows beside each heading sort by that column; click again to reverse. Newest release tells you when each tool last shipped, and Added when we first put it under watch — sort by Added to see the newest additions to the watchlist first (the same list the home page's "recently added" section links to).
• ACTIVITY sparklines each tool's commit volume over the last year, and POPULARITY shows its GitHub stars — sort by either to surface the most actively developed or most popular tools in the landscape.
• The API and MCP columns show a tool's programmable surfaces. A check means the tool offers that surface — click it to open the docs. A highlighted check means we track that surface and diff it over time — click it to open the tool's catalog page instead. A dim dot means we haven't found that surface for this tool.
• LANGUAGES shows which human languages you can use a tool in, so you can check before you roll it out to a team abroad. Click the heading and pick a language to see only the tools offered in it. A dot means we haven't checked that tool yet. Not documented means we checked and found no language listed anywhere we can cite. We list English only where a tool says so, so a tool missing English is probably not English-free. Open a tool to see where each language came from: the tool's own interface files, its documentation, or a release note that announced the translation.
• The ★ heading narrows the table to the tools you've saved.
• Compare up to four tools side by side. Tick the box beside two to four tools and click Compare, or open My Toolchain and click compare there to weigh the tools you've starred. You see pricing and plan changes, the score card, release pace, project health, features and dependencies for each tool, with the leader in each row marked. Pick the sections you care about, hide rows where every tool reads the same, and copy the result as a table or CSV for your own buying notes. Included with every paid plan; pricing history and category ranks are included with Researcher and Business.
• Compare up to four vendors. On the vendors page, tick up to four vendors and click Compare to see every product each one sells, lined up by the market it competes in or month by month. Included with every paid plan.

Click any tool to open its card, which charts three streams of activity across its whole life — release notes, changelog entries, and code commits — alongside the derived signals described below.

The bell in the header shows what changed in the cyber tools you follow since your last visit. We rank the notices so the ones most worth your time come first, and we show five at a time. See all opens the rest.

• Mark a notice Useful or Not useful. Not useful hides that notice.
• Mute a tool and its notices stop showing. You can unmute it under Tune.

Your mutes and your choices stay in your browser. We don't see them. Your follow list is saved there too, and we sync it to your account when you sign in, so it's the same on every device. It doesn't change what we email you. We only count anonymous totals, such as how many notices were shown, and the privacy policy lists them.

Yes. Press ? on any page to see the keys that work there, and pick one of three keyboard modes in that window.

• vim uses single keys. j and k move down and up any list or table and Enter opens the row, g then a letter opens a page (gt for Tools). Space ticks the row you're on for Compare, and s stars it. / goes to the page's filter box, or finds text when there is none. Press Enter in the box to move through just the matches. ] and [ jump between sections. On the subscribe box, j and k move between the plans, and Enter picks one and takes you to the email box.
• emacs uses Control chords. C-n and C-p move, C-c then a letter opens a page, and C-s finds text. It works on a Mac only, because Windows and Linux browsers keep Control-N and Control-P for themselves.
• off turns letter shortcuts off, for screen readers and anyone who prefers Tab.

The arrow keys move between buttons and options in every mode. Your mode is saved in this browser. Sign in and it's saved to your account too, so every device you sign in on uses it. You can also change it on your account page under Customization. With keys off, the keyboard link at the bottom of every page opens the same window.

Hardware tracks the devices you buy for offensive and hardware security work: Flipper Zero, HackRF One, the WiFi Pineapple and the rest of Hak5's kit, Proxmark and Chameleon RFID tools, and the boards you use to probe other hardware. Each device gets a page with the vendor's spec, where it stands in availability, its price and stock on the vendor's store, and the firmware releases that run on it.

• Every number cites its source, and anything we couldn't verify shows as not yet recorded rather than a guess.
• Prices and stock are checked daily on the stores that publish them in a form we can read, and each device page charts the price history for every configuration. A sell-out or a return to stock reaches the daily issue, so you can put a device on your Grep watchlist.
• Firmware sits beside the hardware. A device page lists the official firmware and the community firmware that runs on it, each linked to its release notes. Where the official firmware already has its own page (Flipper Zero, HackRF One), the device facts sit at the top of that page.

Hardware opens the tools table filtered to Hacking Hardware, with each device's form factor, starting price, stock and status in their own columns.

The datasets page lists public malware samples, detection rules, packet captures, attack logs, IOC feeds, deliberately vulnerable targets and payload lists, and prompt-injection corpora you can use to test a product or build detections. Filter and sort it from the column headings, and click a row for a quick look.

• Each dataset has its own page with a summary from the project's README, what's inside it (file counts and types), how to download or install it, and commands for the tools that read its formats — for example suricata -r sample.pcap. The commands are curated; we haven't run them yet, and each page says so.
• Anything carrying live malware is labelled. Those pages lead with a safety note: download and open them only inside an isolated analysis VM with networking disabled. We link to these collections; we never host or mirror them.

Open the tool and follow the features link. Every other view answers "what changed" in reverse-chronological order; the Features page answers "what is this", as one list of the capabilities the tool offers.

• Every feature opens to show what it rests on. Click the + beside one to see the evidence underneath it: the release notes that described it, the tool's own documentation and website, the command-line flags and their help text, the API endpoints, and the output of runs we recorded. Nothing is listed as a feature unless one of those backs it up.
• Lines in monospace are the tool's own words, parsed from its source or its API document. Plain-text lines carry a label that tells you where they came from. Under release, a line is our summary of a dated release, linked to the vendor's own notes. Under docs, it is text quoted from the tool's own documentation or website, linked to the page it came from. Under we ran it, it describes a run we recorded.
• A date is the release date when the vendor dated the release. When it did not, the page shows the month we first saw it, marked "seen", and never presents that as the date the vendor shipped it.
• The list grows and does not reshuffle. A feature keeps its identity as new evidence lands. If the tool renames it, you see the new name. If a release says the capability went away, we mark it retired rather than removing it.
• Where a capability matches our shared vocabulary, it also carries a comparable label — the groundwork for asking which tools do a given thing.

A tool needs at least three evidenced features before it gets a page, so a tool we have only just started watching won't have one yet. Its absence is a statement about our coverage, not about the tool. You may also see no list for a tool whose records we found describe something else, such as a script in its code repository. We hold that list back until we can rebuild it from the tool's own documentation.

The threats page lists every exploited CVE on CISA's KEV list and every attack report we track. Open a threat to see each control you can put in place against it, from finding where the affected product runs to detecting the attack. Each control says whether a cyber tool has public content built for that threat, for the affected product, or only for the attack technique.

• A control is ready when its content names the CVE or the product. Content that only covers the same ATT&CK technique stays greyed out. To see those examples too, turn on "Show technique-level examples" in the threat.
• Exact means the content names the CVE. A Nuclei template or a Metasploit module written for that CVE is exact. Related means the content names the attack technique or the affected product instead.
• A tool is counted once per stage. If it has exact content, it is counted as exact and never again as related, so the two numbers never overlap and you can read them side by side.
• Time to first defense counts days from CISA's listing to the day a tracked cyber tool or open rule set first published content naming the CVE. That day is when the template, rule or module first appeared in its public repository, or the day the rule says it was written. Content published before the listing counts as covered by listing day.
• The list is rebuilt every 2 hours from the KEV catalog, the attack reports and the content each tool and rule set publishes.
• "No published detection rule names this threat yet" is a real answer. We read every open rule set on the list and none names it. The threat then shows the scans and checks you can use first, then the broader rules written for the same attack technique.
• Every reader sees the detection rules that name the threat. We read the open rule sets on the datasets page, such as Sigma, Proofpoint ET Open and YARA. Each rule shows in full with a copy button and a link to its source. A label says what it watches: network, endpoint, web, cloud, identity or file. When a threat has rules of several kinds, you can keep only the ones your sensors run.
• With Researcher or Business you get the tools for each control, with the template, rule or module itself, a link to it, when it last changed, and the command to run it. Run a check only against systems you are authorized to test.

It means we do not read that tool's content for that stage yet, so we cannot say whether it covers a threat. It is not a gap in your tools. A dash, or "No content found", means the opposite: we read that tool's content and found nothing for this threat.

• On a tool page, the threat coverage card appears only for tools whose content we read. It counts the last year's threats the tool has content for.
• When you compare similar tools, a tool that is not indexed is left out of every "only this tool" and "missed" list. Only content that names the CVE decides those lists, and only for stages we read for both tools.

On the toolchain builder you pick an attack type. We take every threat of that type from the last year, and each CVE or technique it uses, at each stage from finding the exposed product to detecting the attack. Then we add tools one at a time, each time the tool that covers the most of what is still open. Included with Researcher and Business. Only indexed tools and documented controls can appear. An empty stage means missing indexed evidence, not proof that your environment is unprotected. Use it as a research shortlist, not a security audit.

• Your tools go first. Start from your saved tools and the builder fills only the gaps they leave.
• Content that names the CVE counts fully. Content that names the technique or the product, or a documented setting, counts half.
• Three suggested tools per stage at most. Each suggestion adds coverage, including useful checks at stages with only a few matches.
• Three coverage numbers, kept apart. You see exact content, related content and documented controls separately, never blended into one score, plus what is still open.

Yes. For tools that publish an OpenAPI/Swagger spec, we snapshot their HTTP API and diff it each day. When endpoints — or their parameters and request/response schemas — are added, removed, or changed, that appears as its own entry in the daily newsletter, independent of whether the tool shipped a release that day. Removed endpoints and newly-required parameters are flagged as breaking. Endpoints newly marked deprecated are called out separately — they still work, so they aren't breaking yet, but the flag is usually the only notice you get before one is removed. The first time we find a tool's spec at all, we say so — with a breakdown of what the API actually covers, one line per capability area, taken from the spec's own descriptions — so you learn both that a tool has an API and whether it does anything you need. Each tracked tool also has an API catalog page grouping its endpoints by capability area, with deprecated ones marked in place, its recent changes, and — when you open an endpoint — its parameters, request body, response shape, and the vendor's own example call. It's reachable from the "APIs" button in the tool's detail card on the Tools page. Plenty of vendors publish an API reference page but no machine-readable spec; for those we watch the reference page itself and report what was added, pulling out newly documented endpoints and any deprecation or sunset notice. Those entries are less precise — the page is prose, so we can quote it but can't always name the exact endpoint — and where a real spec exists we use that.

We give the same treatment to MCP (Model Context Protocol) servers — the surface tools expose for AI agents. Where a tool's repo carries an MCP server, we detect it, extract the tools it exposes, and diff that surface over time; when tools are added or removed, that appears as its own entry in the daily newsletter, independent of any release. Each tracked tool also has an MCP catalog page listing its current tools and recent changes, reachable from the "MCP" button in the tool's detail card on the Tools page.

Yes. Open-source projects announce what they ship in a release, but commercial vendors often don't — the release notes say "various improvements" and the actual launch lands as a press release in the vendor's newsroom. So we watch those newsrooms too, and a genuine product announcement appears as its own entry in the daily newsletter, tagged PRESS and linking to the announcement itself.

"Genuine" is doing real work there. A vendor newsroom is mostly not about the product, and everything that isn't gets dropped: funding rounds and valuations, executive hires and board appointments, analyst-report placements and awards, earnings, conferences and webinars, threat reports and surveys, customer-win announcements, rebrands. What's left — a new product, a substantial new capability, a beta reaching general availability, an acquisition that changes what the product does — is summarized the same way a release is, with the marketing language stripped out. An announcement that never says what actually changed doesn't get an entry. The first time we start watching a vendor's newsroom we read its archive silently, so a decade of old announcements never lands in one issue.

Yes, and it's often where the real detail is. Plenty of features are explained properly in an engineering blog post and get a single line in the changelog — or no line at all. So a vendor's blog is read as its own channel, and a post that announces or documents something the product now does appears in the daily newsletter tagged BLOG, linking to the post.

The filtering is the hard part, because a vendor blog is mostly not product news. Write-ups of vulnerabilities in other people's software, tutorials and how-tos, listicles, opinion pieces, threat reports, compliance explainers, conference recaps, customer stories and hiring posts are all dropped — on one real vendor blog that's 98% of everything published. The test applied to what's left is whether you could do something new with the product after reading it; explaining a capability that already existed doesn't count. As with newsrooms, the first time we start reading a blog we read its archive silently, so years of old posts never land in one issue.

A few of the best-known cyber tools — Nmap and tcpdump among them — ship continuously and cut no GitHub releases at all, so a feed that only watches releases sees nothing from them. For those we read the project's own commits and write the summary ourselves, and every such entry links to the exact range of commits it describes so you can check it. Where the project tagged a version, the entry is pinned to that tag. Where it did not, the entry is labelled "changes since" the date that window opens — not a version number, because the project never said it shipped anything and we won't say it did. Each window normally picks up where the last one we published ended, so one issue's commits aren't described again in the next. Two cases break that and we'd rather say so: the first window for a project has nothing to follow on from, and if a project rewrites its history the commit we were resuming from can disappear, in which case we fall back to a date range and that one window can overlap the previous one. A project that committed nothing in the window gets no entry at all.

Open-source cyber tooling is not permanent — projects get abandoned, absorbed into something larger, renamed, or simply deleted along with the account that hosted them. When a tool we track goes away, we retire it and say so: a "no longer available" entry appears once in the daily newsletter, naming what happened, what we actually checked to establish it, and the successor project where there is one.

A retired tool stays listed rather than being deleted, so links and entries in previously published issues still resolve — it is simply no longer fetched or updated. We deliberately keep this separate from the case where a tool is alive and we merely cannot watch it (a feed goes behind a bot-check, a blog turns JavaScript-only). Calling a live project dead because our own plumbing broke would be a false statement about someone else's work, so those are never announced.

A map of overlaps between authored identities in the Git histories we observed. A link is a candidate for review: it shows the tools, source commits, exclusions and coverage that support the overlap count.

It shows shared authored identities in the Git histories we observed. That does not establish shared maintenance responsibility, employment or dependency. Missing histories remain unknown, and inherited fork commits are excluded from shared authorship. Identity review is required before the graph can support a claim about people or ecosystem fragility.

It names no individuals, and publishes no email addresses. We use the authored identity recorded by Git to count overlaps. The public map shows tools, source commit links and coverage, without publishing a directory of authors. An authored identity is not a verified person; the graph cannot establish who maintains a project or who would replace them.

• A candidate link requires at least 2 authored identities with 5+ commits in both projects, after the declared bot and shared-history exclusions.
• Link weight counts distinct authored identities, not commits. Multiple email addresses and shared addresses require independent identity review.
• Bots are excluded (dependabot alone touches 150 of the repos we watch), as are unconfigured-git placeholder identities like "Your Name", which would otherwise merge dozens of unrelated people into one fictional maintainer.

A missing source history is distinct from a fully observed repository with no shared identities. Source coverage and reviewed exclusions remain visible.

A subscriber view on every tool page: five scores from 0 to 100 — shipping velocity, documentation quality, breaking-change discipline, maintenance risk, and innovation and surface — and, on open-source tools, four community-health scores: whether contributors are growing, whether the project is narrowing onto fewer maintainers, whether its issue backlog is shrinking, and how fast maintainers reply. Each is computed from data the site already shows, with a link to that data. Open-source tools are scored on their repositories; commercial tools on their published changelogs, and the card says which. A dimension we cannot measure reads "not measured" and is never scored 0. Whether a vendor is a specialist, a suite or a consolidator is shown too, but never scored — which one you want depends on you. The method is under "How this is scored" on any tool page.

The scores come with every paid plan, and on the score card page you can pick up to six tools and read their cards side by side. Coverage varies by tool, category and period. Researcher and Business add where the tool stands among measured tools in its category (a rank always carries its denominator, and a category with too few measured tools gets no rank at all), the measured peer table and, where history is available, quarterly changes in standing. Your toolchain card averages only tools measured on each dimension and shows the count; missing data never counts as zero.

Capability search lets you combine up to six terms, including at most five capabilities, joined with "and", "or" and "but not", across the features and vendor pages we have indexed, narrowed to a category or a few tools if you choose. Coverage varies by tool; the catalog is broader than the evidence indexed for any one capability. Each matching tool lists the proof: a feature the vendor documented, or a sentence on the tool's own README, docs or website, quoted word for word with a link. A model reads each candidate first and keeps it only when the tool itself offers the capability, so a feature that merely works with another product's API or SSO is not counted. Neither is one that only mentions it in passing without saying what it does. Open a row to see every place the tool says it. A quote from a page shows the day we last read that page and when we'll read it again. We re-read those pages every day, so if the words are gone, the cell says "No longer on the page" and when the page last said it, instead of an old quote. Short names work too: sso, mfa, api, sbom, saml. A short name can expand to several capabilities; if that exceeds the limit, choose a more specific name or remove a condition. Put a term in quotes to search for its words instead of resolving it as a capability. The line under the search box says when the results were last updated. A page you leave open picks up newer results within about ten minutes, and the proof you open always comes from the same update as the list you are reading. If we cannot reach the latest results, the page says "Using earlier data" and keeps working.

A tool without a match reads one of two ways. No documented match means we looked and found nothing we can quote. We haven't looked yet means just that: we haven't read that tool's docs for this capability, so it says nothing either way. If you know, the Tell us link next to it sends us the answer. Where we know when a feature arrived and you've told us which version of a tool you run, a cell can also say why, such as "Added in 3.0, after your version". Open a row and the detail may add a note, such as "Not confirmed in what this tool publishes" or "Mentioned only in passing in what this tool publishes". None of them is a claim that the tool lacks it, so check the vendor's own docs before you rule a tool out. With "but not", a tool is left out when anything it publishes mentions what you asked to leave out, even unconfirmed. A tool with too few features on record is not listed at all, because we cannot say what it leaves out. Found a match we got wrong? Tell us. Everything here is open to everyone: search by capability, word or mitigation with no account, open any tool to read the release notes and docs that show it, and download the table.

My Toolchain is a five-step page for the cyber tools you run. List up to ten, one per line, with a version after the name if you know it. Then you can check where they cover what you need, see the handoffs between them that we have tested ourselves, see what changed in them lately, and, two weeks after we show you a handoff, tell us whether you used it. You can also start from a single tool, a threat or a category instead of typing a list.

We sync your tools to your account when you're signed in. Your versions stay in your browser until you choose Keep my versions, which needs you to be signed in. Keeping them is what lets us ask you about a handoff two weeks later. You can erase them from the same page at any time, and deleting your account erases everything. We don't publish any of it or use it to train anything. Checking coverage sends your tool names to us for that one answer, and the versions only when you've given them. A coverage check is included with Researcher and Business. If a step says "not available yet", it isn't switched on for your account, which is different from there being nothing to show.

A history of how the tool's vendor prices and packages what it sells, read from the vendor's own pricing page over time: the plans on that page as we last read them — price, description and what each includes — and every point at which the lineup changed, with the date, the gap since the reading before, what each plan gained or lost, and a plain-language note on what the change means for someone buying the tool. The same history, in full, opens in a detail window from Vendors, so you can return to the same search and place in the list. You can also open the vendor's own page from that window. Offerings sold without a list price, such as a managed service, are on the board too. When the pricing page sends you to a separate page of plans for each offering, those plans are shown under the board, as of the last time we read that page.

It is part of Researcher and Business. Everything in it is quoted from the vendor's page on the date we read it. A plan that stops appearing is shown as no longer listed on the page — which says what we read, not that the product was withdrawn — and a reading that failed to show any plans is left out rather than counted as a change. A plan that vanishes from one reading and is back in the next is treated the same way: that reading was of a half-loaded page, not a withdrawal and a relaunch, so a plan counts as withdrawn only once a later reading confirms it is gone. Only vendors whose pricing page we have read at least three times get a history.

You can see how the vendor's own website has changed: the home page, the pricing and packaging page, the product page, and every page its main menu and homepage link to, such as each product and solution page. We visit the home, pricing and product pages every day and the menu's pages every week, and keep a new frame only when the page really changed, a new headline, new colours, a reworked layout or rewritten copy, and the change was still there the next day. A rotating banner or a one-day promotion is not kept. The time before our daily visits began is filled in month by month from the Wayback Machine's copies, back to 2021 where it has them. Step through the frames with the arrow keys or h and l, play them as a time-lapse, or put any two side by side. The comparison starts a year apart, since that is where the changes show. Beside each frame you see the page's tagline and the colours it used, and the timeline marks the frames where something changed, so a rebrand, a repositioning or a new pricing page is one keypress away. The same history is on the vendor's page, and on Website history under Vendors you can type any vendor's name to find theirs. Each analysed step adds an AI summary of the changes since the preceding snapshot. Vendors and the free samples label a rebrand only once we have confirmed it. With a plan, the rebranding timeline and yearly charts also show possible rebrands, marked as AI suggestions and kept apart from renames the vendor's site states outright. Dates show the interval between the old and new snapshots, not an assumed launch day. Counts describe the vendors we track; unanalysed history is shown as missing coverage.

Included with Researcher and Business. You can try two vendors' histories free on the Website history page, no account needed. A frame from our daily visit is labelled with its day; an older one is labelled with its month and shows the page as the Wayback Machine saved it, unchanged. A month it has no copy of is not shown. A change to a vendor's home, pricing or product page usually appears here within two days, and to a menu page within about a week. Menu pages are under More pages, by the menu's own names; one we have just started following fills in from the Wayback Machine over the following weeks. Summaries are added as analysis completes; historical comparisons are being filled in. Uniq includes a recent rebrand only when the vendor's own site states the new name. You get dated before-and-after snapshots and a short summary. A change the AI only suspects stays out of Uniq, and newly found historical changes are not presented as current news.

The threads from that tool's mailing lists, forums and other community discussion that are worth your time: the ones that explain a behaviour, settle how to do something, or flag a change you have to handle. Each card is summarised, dated, and linked to the original thread. Commands a thread validated appear with the year they were written and why they are shown: a maintainer or contributor posted them, a maintainer confirmed them, the asker reported they worked, or real output followed. Posters appear by role, never by name. Many threads also carry a short box that tells you what you can rely on: whether the change shipped, was merged, or is only proposed, which versions and setups it applies to, and what to do next. Open "From the thread" to read the exact lines it is based on. When that check is more than six months old, the box says it needs re-checking.

Articles from around the web that name the tool, so you can learn it, see how it shows up in real attacks, and read what happened when it was part of a breach. They are grouped into tutorials and guides, attacks the tool was used in, breach post-mortems and incident response write-ups, and attacks on the tool itself. Reports that name a tool without establishing its role appear under "Mentioned in attack reports". "Used in the wild" requires a source statement or a reviewed attacker-tool label. Each row links to the original article with its publisher and date, newest first. Under it are up to three short quotes, the article's own sentences that name the tool. A vendor's own blog never counts as an article about that vendor's products. Links are checked every week, and an article whose page is gone is removed. A tool with no articles has no section.

It shows when a tool's own releases were compromised, such as a poisoned package or a hijacked release pipeline. Each incident lists the exact versions, images and time windows that were affected, what the maintainers say to do, and links to their report, so you can check whether a build you ran is one of them. We don't show a suspected incident. One appears once the maintainers, an OSV malicious-package record or two independent reports confirm it, and we label whether it is contained, whether a clean release is out, and whether anyone has disputed it. It can't tell you whether your own systems were affected, so check what you installed. A CVE or other advisory about a tool appears on its timeline labelled "advisory" and does not count as a release. A tool with no incidents has no section.

Its page moves to the new name and lists every name it has had, oldest first. We change a name only after we've seen the vendor say so in public. Nothing you rely on breaks:

• Old links and bookmarks take you to the new page, to the same section when it still exists. If a section is gone, the page tells you.
• If two tools once had the same name, the old address lists both so you can pick.
• Tools you saved follow the new name the next time you visit.
• Searching the old name still finds the tool.

Tail and Uniq report each name change once, to every reader. It isn't a release, so it never counts toward a Grep or your watchlist alerts.

Six things the raw data can tell you that a README won't, computed from the tool's full commit history and its release notes:

• Bus factor — how many people this project actually is. If one person wrote most of it, that's a supply-chain fact worth knowing before you build on it. (sudo: one maintainer, 98% of 15,000 commits.)
• Top contributor org — who funds the work, inferred from the email domains in the commit history. See the caveat below.
• Cadence — whether the code and the releases are moving together. Building means commits are up but releases have paused: something is coming. Coasting means releases still trickle out while the code has gone quiet — often the last thing that happens before a project stops.
• Breaking releases — what share of this tool's releases contained a breaking change. The practical question: how often does upgrading this thing cost me an afternoon?
• Contributors — whether the contributor base is growing or shrinking. People leave before the commits stop, and the commits stop before the releases do.
• Work mix — new capability versus firefighting, from commit subjects.

Every signal shows the evidence it rests on, because a bus factor drawn from three commits is not the same claim as one drawn from three thousand. Where the evidence is too thin to support a number, we show nothing rather than guess. The same goes for a product whose public repository is only its issue tracker or release mirror: its commits are not where the product is built, so we show no commit-based signals for it at all. A signal from the commit history that was counted on an earlier day shows that day, so you can tell how recent it is.

We look at the email domains in the commit history: work done from an @sysdig.com address is work Sysdig paid for. But most open-source developers commit from a personal address even when they're employed to do the work — so a large share of any project's history simply cannot be attributed to anyone. That's why the card reports the org's share of the commits we could attribute, and tells you what fraction of the history that was.

Read it accordingly. "Sysdig, 86% of attributable commits — 12% of history is attributable" means: of the small slice we can trace to an employer, Sysdig dominates. It does not mean the other 88% is independent volunteers. We also ignore domains with only one author behind them — a lone maintainer's own domain is a vanity address, not a company.

All the way. The commit line is the repository's entire history — for Falco that's every month since 2016, for some tools back to the 1990s. We read it from the git history itself rather than from an API that only reports a rolling year, so a quiet month inside the span is a real quiet month, not missing data.

The release-notes and changelog lines run the full span too. Commercial products with no repository we watch have no commit line at all.

They describe how recently a tool's repository was last pushed to — any commit, on any branch, not just a tagged release: active within the last 30 days, maintained within 90, and stale beyond that. For a tool with no repository we watch (most commercial products), the date of its last tracked release stands in. Tools with neither signal show as unknown. It's a rough liveness cue for the watchlist, not a quality judgment — some excellent, finished tools sit still for a year.

Star the tools you actually run and the site adapts to them. The ★ filter narrows any newsletter issue and the Tools page down to just your tools, and the my toolchain panel (the chip in the corner, on every page) lists them together and lets you pin the version you're running to get an upgrade digest. It also shows what has shipped for your tools — the last 30 days' worth until you dismiss it, and everything since your last visit after that. Expand it to read the releases themselves; you can only dismiss the list once you've opened it.

You don't need an account. Your starred tools and version pins live in your browser's local storage. Sign in and we'll sync your starred tools to your account, so they're on every device you sign in on. It doesn't change what we email you. Version pins stay in the browser, and clearing your site data clears them. Use the "copy link to my toolchain" button if you want to carry the set to another browser or share it, or export an OPML file to subscribe to your tools in a feed reader.

Every entry on the site is written as news, addressed to a reader who is already on the latest version. Almost nobody is. So in the my toolchain panel you can pin the version of a tool you actually run, and the site rolls up every release since then into one answer: what you'd gain, what would break, and which commands changed. It also appears on the tool's own page once you've pinned it.

A digest only covers releases we have an entry for, and it always says so — "covers 0.38 → 0.44 (7 releases)". If you're further back than the releases we cover, pick older / not listed and it will tell you where our coverage starts rather than pretend to be complete.

Same way we write everything else: from the vendor's own release notes. A breaking change is something that will break a working setup when you upgrade — a renamed or removed flag, field, API, or config key; a changed default; a dropped platform; a required migration. They're kept separate from the feature bullets, because they answer the opposite question.

An LLM extracts them and a second pass verifies each one against the source material, rejecting anything the notes don't actually say — a false breaking change is worse than a missing one, since it would scare you off an upgrade you should have taken. They're only as good as the notes, though: if a vendor ships a breaking change and doesn't write it down, we can't surface it. Never treat a digest as a substitute for the vendor's own upgrade guide.

Two ways, depending on how much you need. For following releases, the site publishes machine-readable feeds — no key, no account, free:

• The Feeds page is the front door to all of this — RSS and OPML, newsletter / category / per-tool, each with a copyable URL.
• /rss.xml — every release issue (Tail + Head), RSS 2.0.
• /newsletter/releases.xml, /newsletter/highlights.xml, /newsletter/docs.xml — each newsletter series as its own RSS feed.
• /feeds/category/<category>.xml — one aggregate feed per tool category (the newest release of every tool in it), plus a .opml bundle at the same path to subscribe to each tool in the category individually.
• /tools/<tool>/rss.xml — one feed per tool, an item per release. Follow only the tools you run instead of the whole firehose. The my toolchain panel will export an OPML file of your starred tools' feeds, and /feeds/all-tools.opml bundles every watched tool's feed — either imports into any feed reader in one go.
• /tools.json — every tool that has shipped a tracked release, with its newest one.
• /entries.json — every entry from every issue, flattened.
• /toolchain-catalog.json — the full watchlist, the catalog behind "my toolchain".
• /search-index.json — what ⌘K searches: every tool, issue and newsletter.
• /stack-index.json — the lookup behind paste-to-detect-your-stack.
• /llms.txt — a summary of the site for LLMs.

For querying instead of following — filtering releases across the whole watchlist, pulling a tool's SBOM or recorded CLI examples directly, reading analytics as data — there's an authenticated API for Researcher and Business subscribers. Generate a key from your account page.

Yes. Researcher and Business subscribers can use an existing API key with the MCP server to read and change newsletter settings, count their Greps, inspect each Grep's tools, categories and keywords, and create, edit, pause, resume or delete a Grep. Changes also appear on your account page. Your existing plan limits still apply. The key authorizes these changes; only connect it to assistants you trust to manage your newsletters.

Your assistant can also list subscriber issues you are entitled to read and retrieve their available content and page or download links. Access follows your current plan, the site your key belongs to, and when you subscribed. Billing and API-key management stay on the website. To delete your account, use Delete account on My account.

Press ⌘K (or Ctrl-K) anywhere on the site to jump straight to any tool or any issue.

Search the chart library by name or topic, filter by category and data confidence, and browse nine previews at a time. Choose Expand for the interactive chart, its controls and source notes. Full screen gives it more room; closing returns you to your filters and place in the library. Analytics shows observed release activity, release-note rubric scores, feature classifications, maintenance signals, recorded service incidents and source-linked company events. Each chart states its unit, population, observation period and collection gaps. Company views describe the recorded cohort and event-date precision; unknown operating status remains unknown, and watched companies do not establish a whole-market denominator or customer demand. Public attack reports describe recorded reporting, rather than attack prevalence. Unknown tool classifications are kept separate from reviewed results. Each chart carries a confidence grade: Solid for a reproducible measure that passes its evidence checks, Outdated when the evidence is older than the chart allows, Incomplete for missing evidence, and Don't trust yet for a known contradiction. An Outdated chart still shows what we had, with the date we last collected it, so you can see it isn't current. Contradictory charts keep their coverage and source details visible while the affected visualization is withheld.

Defect analysis reports fix-bullet categories, their concentration and variety, fix-bullet share, and recurrence of a category. Unmatched text and low-sample tools remain explicit. Recurrence means another fix in the same category; engineering effort and a failed earlier fix need separate evidence. Many charts are readable without an account; some mask tool or category names, and others are for Researcher and Business.

Solid requires a reproducible measure with retained source evidence, a defined unit and population, current observations, and the independent review its subject needs. Every chart shows its period, observation date, measured coverage and gaps. A fresh page build does not refresh old data, and the grade expires when its evidence does.

Missing data stays unknown, rather than becoming zero. Hiring opens on the latest observed snapshot; monthly trends require three completed months of real observations. Remote-region eligibility can overlap. Incident counts describe observed component activity, not platform uptime. Attention uses a matched signal with 26 complete baseline weeks and four recent weeks, or explicitly labeled genuine observation intervals. Classified signals need independent human review. Unavailable comparisons keep their source ledger and explain which evidence is still needed.

Some available charts mask named tools, platforms and categories, such as release-note rubric scores, observed incident activity and fix-category recurrence. Their observed values, coverage and evidence limits remain visible. Researcher and Business subscribers see the names and can access the charts included in their plans. The tools directory and every issue are open to everyone.

Every chart carries its own "about this data" note saying what it counts. Paid plans also get the methodology, which explains each measure, its exclusions and the limits of the available evidence.

We read the vendor's public status page and report incident counts and bounded reported incident time for the stated components and observation interval. Informational and scheduled-maintenance notices are excluded. Overlapping intervals count once within that scope; missing durations and incomplete records stay explicit.

These are vendor-reported incidents, not a measurement of platform uptime. A component incident does not establish a platform-wide outage, and an incident the vendor never publishes is unavailable to us. A comparative ranking requires a verified common 90-day window and compatible component coverage. Otherwise the chart shows source coverage and observed activity without claiming that one platform is more reliable.

With verified release history, the chart compares the gap since a tool's last observed release or supported tag against its own observed cadence. Collection gaps, changed repository identities and stale evidence remain visible. A tool that normally ships once a year should not be judged by the same gap as one that usually ships every fortnight.

This describes observed release activity. A finished tool can stop shipping, and a repository can remain actively developed without cutting releases. Read the dates, source coverage and usual cadence as a prompt to investigate the project, never as proof that it is dead or abandoned.

Eligible release notes receive a fixed 0–100 rubric score for depth (explanation, sections, change bullets and supporting links), usage examples (code, commands or configuration), and transparency (breaking changes, upgrade guidance, security advisories and deprecations). A tool's score represents the median note among its most recent 10 valid notes in the last 24 months. The selected note's three contributions add to its total, and the drill-down shows the dated notes and channel used.

Ranking requires at least three valid notes and a verified product-specific channel, with alternative channels reviewed. The selected channel is the highest-scoring verified channel in that scope: releases, a repository changelog or a curated publisher page. Missing, unavailable or unresolved channels remain unassessed. A measured zero means the collected notes scored zero on this rubric; it does not prove that no notes exist. The over-time view scores each completed quarter separately, using at least three dated notes per tool. The tracked-tools line gives each tool equal weight and appears only with ten scored tools. Blank quarters mean we lack enough dated notes, not that the notes scored zero. A newly found documentation channel can change a score, so check the linked sources before treating a rise as better writing. The initial history reconstructs the published snapshot's at-most-ten reviewed notes per tool, so older or unselected releases may not appear. These are reproducible rubric scores, with review limits stated beside the chart, rather than a judgment of the software or all its documentation.

Articles is the long-form side of the project — field notes on cyber tooling, product craft, and the work behind building and buying security products. They're separate from the newsletter: the newsletter tracks what shipped this week, an article works one subject through end to end.

• The newest piece is featured at the top; the rest run as an archive grid you can narrow by topic with the chips above it.
• Longer pieces carry a contents rail on wide screens and a reading-progress bar at the top of the window, so you can see where you are in a piece.
• Everything is free and there's no paywall or signup. Each article also links back to its original post on Substack.

Articles are searchable from the command palette (⌘K / Ctrl-K) by title, topic, or what they're about — not just the exact headline.

From the tools themselves. We watch more than 1,300 tools and hardware devices every day. For tools, we read GitHub and GitLab release feeds for open-source projects, and vendor changelogs and documentation pages for commercial products. For hardware, we read each vendor's own product and store pages. What we publish about a tool comes from what its vendor or maintainer wrote: release notes, changelogs and docs. It does not come from press coverage or rumor.

Yes, and it's worth being precise about which parts. We use a mix of frontier and open-weight LLMs and pick the model for each task.

• An LLM writes the summaries. Every entry, including the headline, the feature bullets, and the usage examples, is written from the vendor's own release notes and documentation.
• An LLM picks the weekly highlights, comparing the week's releases against each other.
• An LLM groups a tool's feature list. Every tool page links to a Features page listing what that tool does. The model has one job there, which is to group evidence we already hold into capabilities and name each one. It never writes the evidence. Every line you can expand under a feature is a release note we published, a flag's help text parsed from the tool's own source, an endpoint from its API document, or the output of a run we recorded. A proposed feature with no evidence behind it is discarded rather than published.
• An LLM explains the recorded runs. On a tool page, the "Explain it" panel under a recorded command is written from that run's own output and the fixture answer key — what it was pointed at, and what came back. Every figure in it is checked against the recording, and an explanation that mentions a number the run never printed is thrown away rather than published. The command and the output above it are the recording itself, untouched.
• An LLM sorts some articles by kind. A few of the sites behind a tool page's Articles section publish tutorials and attack reports side by side. For those, a small model reads the post's public text and says which kind it is. It writes nothing you read: the title, publisher and date come from the article itself.
• An LLM explains the technology an entry names. Wherever an entry mentions something a tool is built on (AF_XDP, AWS ENA, ML-KEM), in its summary, its feature list or its examples, explained terms carry a dotted underline. You can also find these explanations in tool-page introductions and summaries. Hover, focus with your keyboard or tap a term for a short explanation. Each term is explained once and reused everywhere it appears, the tool's own features are never treated as terms, and a definition we are not confident in is dropped rather than shown. Some of them are written by hand.
• Humans decide what gets watched. The source list, the categories, and the documentation pages tracked are all curated by hand.
• No human approves each issue before it publishes. The daily pipeline runs, builds, and deploys on its own, and Jon reviews the data regularly but after the fact. See How do you keep the data accurate? below.

The summarizer is constrained against inventing things: a flag, setting, or API can only appear in an example if it appears verbatim in the source material, and an entry that fails to summarize cleanly is dropped rather than shipped. It is still a language model, so errors are possible — if you spot one, use the feedback form or email me and it'll get fixed.

This only works if you can trust it, so the pipeline enforces these rules.

• Primary sources only. Everything published is derived from what the vendor or maintainer wrote themselves — release notes, changelogs, docs, press releases — never from press coverage, rumor, or another newsletter.
• Nothing is invented. A flag, setting, or API can only appear in an example if it appears verbatim in the source material, and an entry that can't be summarized cleanly is dropped rather than shipped. Breaking changes get a second pass that re-checks each one against the source and rejects anything the notes don't actually say — a false breaking change is worse than a missing one, since it would scare you off an upgrade you should have taken.
• Every figure in a run explanation is checked against the recording. On a tool page, an explanation that mentions a number the command never printed is thrown away rather than published. The command and its output are the recording itself, untouched.
• "Not checked" never renders as "nothing found". A tool that hasn't been analyzed for something looks different from one analyzed and found clean. We don't manufacture all-clears — silence means we don't know, and the page says so.
• The source list is a gate. A miscategorized or malformed source stops the whole run instead of quietly publishing wrong data, and every item is keyed so the same release can't reappear as if it were new.
• A human reads it. Jon reviews the data regularly once it's live — spot-checking entries against the vendor's own notes, correcting anything he finds, and tightening the pipeline when a class of error shows up rather than patching the single entry.

What this doesn't guarantee. We can only be as good as what vendors write down, so if a project ships a breaking change and doesn't document it, we can't report it, and a vague "various improvements" stays vague. A human reviews the data regularly, but only after publication, since no one signs off on each issue before it goes out, and a language model does the writing, so errors are possible. We keep the vendor's original text behind every entry so you can trace any claim back to its source, and if something looks wrong, use the feedback form or email me and I'll fix it. Don't treat a digest as a substitute for the vendor's own upgrade guide.

Coverage tracks documented additions, updates, and retirements of vulnerability checks, detections, integrations, platform support, and compliance policies. Each tool page sums up what changed, lists every change with its date and a link to the source, and charts it by month once there are two months or more. Counts describe documented changes, not a complete inventory, detection effectiveness, or engineering investment. A date marked Seen is when we first found the change; it is not a confirmed release date. Missing data is unknown.

Yes. On your account page, turn off Include Coverage updates in my emails and save. This omits routine Coverage from Tail, Head, Diff, and Grep emails for this site, including matching interests. Updates we have not sorted yet still arrive, so a product change is not held back. Major product capabilities can still appear. Your interests stay saved and tool pages keep their Coverage. New-tool announcements, pricing reports, and benchmark results are unaffected.

Researcher and Business subscribers can add a connector, CVE, platform, or capability under Topics and capabilities in a Grep. Keywords match whole words or consecutive phrases in published text and Coverage titles and targets. Tools, categories, and keywords each add matches; keywords do not narrow the tools you select. Matching does not search full release notes or infer intent. Coverage matches are omitted when your Coverage email setting is off.

Routine bug fixes, crash patches, dependency bumps, and refactoring are filtered out. A tool fixing a vulnerability in its own code is also excluded unless the release contains an independently meaningful capability. New or updated checks that detect vulnerabilities in other software are tracked separately as Coverage.

Most readers run the stable release, so prereleases (release candidates, betas, nightly builds) are hidden on the newsletter pages until you click show prereleases. We remember that choice in this browser. In email they're off too, unless you turn on Include prereleases in my emails under Customization on your account. The Developer edition includes them already, because people building on a tool want to see what's coming.

Ask. Send the tool through the feedback form or by email — open-source or commercial, both are welcome. It helps to include the repo or the changelog page and where the product documentation lives, since those are what get monitored. Once we start watching it, it appears in that week's New on the Toolchain.