I keep seeing the claim that running a bug bounty program is how a vendor speeds up remediation. The argument is intuitive: a platform, triagers, a payout, a dashboard, all of it built to move a report from inbox to fix. Against that you have the old path, a researcher emailing security@vendor.com and hoping someone reads it.
I have used both paths in the same year for the same class of vulnerability. The bounty program was not reliably faster to an actual patch. Sometimes it was slower. What follows is not an argument against bounties, which are clearly good for other reasons. It is a look at where the time actually goes between a report and a shipped fix, and why the money in the pipeline does not buy the part of the timeline that matters most.
A responsible disclosure over email and a submission through a bounty platform are optimizing different things, and it took me a while to see that clearly.
The email path optimizes nothing. It is a queue with no service level, no acknowledgement guarantee, and no structure. When it works, it works because a specific competent person on the other side read the message and cared. When it fails, it fails silently, which is its own problem and the reason platforms exist at all.
The bounty path optimizes triage throughput and researcher payout. Those are real and worth having. A good platform gets you a fast acknowledgement, a severity decision, and a duplicate check, usually within a day or two. What it does not optimize, and cannot, is the vendor’s internal engineering schedule. The fix still has to be written, reviewed, regression-tested, and shipped through whatever release process the product already has. No triager controls that queue.
So the honest framing is: the platform compresses the front of the timeline, the part between “I sent it” and “someone confirmed it is real.” It does very little to the back of the timeline, the part between “confirmed real” and “patched in a release customers run.” And on the reports I have handled, the back half is where almost all of the calendar time lives.
Two reports, same year, same underlying weakness class (an authorization check missing on a secondary endpoint). I am keeping the vendors anonymous because the point is the shape, not the names.
| Milestone | Bounty platform | Email to security@ |
|---|---|---|
| Report submitted | Day 0 | Day 0 |
| Human acknowledgement | Day 1 | Day 6 |
| Severity agreed | Day 3 | Day 9 |
| Fix in a released version | Day 74 | Day 51 |
| Public coordination complete | Day 90 | Day 65 |
The platform won the first three rows and lost the two that a defender actually cares about. The email vendor was slower to answer, then faster to a shipped fix, because the team that read the email owned the release and scheduled it directly. On the platform, the report cleared triage quickly and then sat in a backlog that the triagers did not control, waiting on an engineering team that treated the platform as an intake system rather than a priority signal.
This is one comparison and I would not build a law out of it. But it matches what I have seen repeatedly. The bounty acknowledgement is a customer-service metric. The patch date is an engineering-capacity metric. They are not the same number and paying for the first does not move the second.
A related belief is that a high CVSS base score makes the fix go faster. I score every report I send, and I have watched high scores fail to move anything. CVSS v3.1 base measures how bad the bug is if exploited, not how likely a vendor is to prioritize it against its own roadmap. A 9.8 in a rarely-deployed feature can lose the internal queue to a 6.5 in the login path that support is already getting tickets about. The score is an input to the vendor’s decision, not a lever the researcher gets to pull.
What actually moved timelines, in my experience, was none of the things the bounty economics are built around:
Here is the part the economics discussion usually skips. While the report moves through either pipeline, the vulnerability is still live in every deployment running the affected version. The bounty payout does not shorten that window for the vendor’s customers. The customers are exposed from the moment the bug exists to the moment they install the fix, which is strictly later than the moment the vendor ships it.
That gap is not the researcher’s to close and it is not the platform’s either. It belongs to whoever is watching the affected systems in the meantime. Plenty of organizations do not wait for a vendor’s timeline at all, because they cannot afford to; they run continuous detection on the exposure window itself, either with an in-house team or by handing that watch to an outsourced SOC that treats the interval between disclosure and patch as the thing to monitor. That is a different economic decision than the vendor’s, and a more honest one, because it assumes the patch will be late and plans for the window rather than the milestone. The public coordination frameworks, from the FIRST guidelines to the CERT/CC coordinated disclosure guide, are all careful to describe that window as a shared-risk period, not a vendor-only one, and they are right to.
Yes, but not for the reason usually given. A bounty program is worth running because it opens a channel that would otherwise be a silent security@ inbox, it pays researchers who would otherwise be working for free, and it catches the reports that the email path loses entirely. Those are real benefits and I am not waving them off.
Just do not sell it as a speed-to-patch improvement, because on the metric that protects customers, the shipped fix, it mostly is not. The compression it buys is at the front of the timeline, and the front of the timeline was never the expensive part. If a vendor wants faster fixes, the money is better spent on the engineering capacity to turn a confirmed report into a release, and on making sure the person who triages a report can also get it scheduled. That is unglamorous and it does not come with a dashboard. It is also the only thing I have seen actually move the date that matters.
]]>A while ago I wrote about getting quietly deprioritized by a vendor after handling a disclosure badly. That post was about the relationship. This one is about the artifact: the report itself, and why some of mine get acknowledged and scheduled inside a single patch cycle while others sit in triage for weeks.
The uncomfortable finding, after enough of both kinds, is that the difference is usually not the severity of the bug. It is whether the first person who opens the report can reproduce it and re-state the impact in one sentence without asking me anything. Almost everything below serves those two goals.
A vendor’s intake queue is triaged by someone who has ten other reports open and no context on my finding. The report has to survive that reader. I structure every one around the same fields, in this order, because it front-loads the decision:
| Field | What goes in it | Why it is first-read material |
|---|---|---|
| One-line impact | “Unauthenticated attacker can read arbitrary files as the web user” | The triager can route and rank from this alone |
| Affected versions | Exact build strings I tested, not “latest” | Tells them whether it is still live in a supported release |
| Preconditions | Default config? Auth required? Non-default feature? | Separates “critical” from “critical if you enabled X” |
| Reproduction | Numbered steps, exact requests, expected vs actual | This is the part that gets it fixed or ignored |
| Suggested severity | A full CVSS vector, not just a number | Shows the work; invites correction rather than a fight |
| Remediation | What a fix would need to do | Saves the engineer a step and signals good faith |
The single highest-leverage line is the one-line impact. If a busy reader has to assemble the impact themselves from a wall of technical detail, the report drops down the queue until someone has time. If it is stated in the first sentence and the reproduction backs it up, it gets scheduled.
Everything else is framing around this section. A reproduction that a triager can paste into their own environment and watch fail is worth more than any amount of prose about how serious the issue is. What I have learned to include, every time:
The technical work is usually the easy half. These are the writing choices that, in my experience, move a report faster:
The inverse is just as consistent. The reports of mine that stalled shared some combination of: a vague reproduction that needed a follow-up email before anyone could confirm it, an inflated severity that the vendor spent their first reply arguing down instead of scheduling a fix, multiple loosely-related bugs in one thread, and an adversarial tone that turned a technical exchange into a defensive one. None of those are research failures. They are all report failures, and they are all avoidable.
The through-line with the vendor-patching-cadence data is that vendors are faster than their reputation when the report does not make them work to understand it. The severity of the bug sets the ceiling on how fast it should be fixed. The quality of the report determines whether it gets anywhere near that ceiling. I spend more time on the write-up now than I used to, and it has done more for my fix rates than any improvement in the actual finding.
]]>This is not a vulnerability writeup. There is no CVE ID at the bottom and no affected-versions table. It is process commentary, which is a genre I usually avoid because it tends toward complaint, and complaint is not useful.
The reason I am writing it anyway is that one of my disclosures went badly in a way that was mostly my own doing, and the lesson took a few years to fully land. Somewhere in 2021 I got myself onto a vendor’s informal bad list. Not banned, nothing dramatic. Just deprioritized. My subsequent reports to that vendor sat in triage longer, got terser replies, and in one case were closed as “working as intended” on a finding that a different vendor would have fixed. I earned that. This post is about how.
I am going to keep the vendor anonymous, because naming them would make this the exact kind of adversarial post that caused the problem in the first place. Call them a mid-size networking-equipment vendor with a real but overworked product security team.
The published models for coordinated vulnerability disclosure are good, and I still believe in them. If you have never read them end to end, they are worth the afternoon:
All of them describe roughly the same pipeline: the researcher reports privately, the vendor acknowledges and triages, both sides agree a timeline, the fix ships, and public disclosure follows. The documents are careful to frame this as a negotiation between parties with different incentives, not a rulebook that one side enforces on the other. That framing is the part I missed at the time.
Here is the disclosure that went wrong, reconstructed from my own notes.
| Date | What happened |
|---|---|
| 2021-03-02 | Reported an authenticated command-injection issue to the vendor’s security alias. First email included a full writeup, a CVSS vector, and a line stating I would publish in 90 days. |
| 2021-03-09 | No acknowledgement. Sent a follow-up referencing the 90-day clock again. |
| 2021-03-18 | Vendor acknowledged. Reply was noticeably cool. Asked me to “not treat this as a countdown.” |
| 2021-04 to 2021-06 | Slow back-and-forth. I sent two more timeline reminders. The fix slipped past the window I had set. |
| 2021-06-30 | I published, on schedule, because that was the deadline I had stated. The patch shipped nine days later. |
Read that table as a vendor and the problem is obvious. I led with a deadline before they had even confirmed receipt. I treated a 90-day window, which is a reasonable default, as a contractual obligation I was entitled to enforce from the first message. I sent reminders that a busy triage engineer reads as pressure, not as help. And I published on the exact day I had threatened to, while a fix was visibly in flight, because I had decided the date mattered more than the outcome.
None of the individual steps violated any disclosure norm. Ninety days is standard. Publishing at the deadline is defensible. But the aggregate signal I sent was “this person is adversarial and will not flex,” and the humans on the other end responded to that signal the way humans do. The next time I showed up in their queue, I was the researcher who published on them.
The disclosure documents describe incentives and timelines. What they do not capture is that coordination runs on a small number of specific people who remember you. A vendor security team is usually two or three overworked engineers, not an institution. If you make one of those people’s week harder for no reason, you are not disputing a policy, you are annoying a colleague you will need again. The RFC-shaped model quietly assumes both sides are interchangeable functionaries. They are not.
The second thing the standards underweight is the defender who is exposed while all of this plays out. My nine-day gap between publication and patch was a gap I created, and during it, every operator running that product was more exposed because I wanted to make a point about deadlines. That is the cost that never shows up in the researcher’s ledger, because the researcher does not carry it.
This is where the disclosure process stops being an abstract negotiation and turns into someone’s actual Tuesday. Between the moment a vulnerability becomes public and the moment a given organization has actually deployed the fix, detection is the only control that helps, and most organizations do not staff for it. It is the reason the CISA Known Exploited Vulnerabilities catalog exists as a forcing function, and the reason FIRST’s guidance spends so much time on the exposure window rather than the fix itself. For teams that cannot watch that window themselves, it is also the entire premise of a managed-detection outfit like the Falconer Security team: someone whose job is the interval between disclosure and remediation, which is precisely the interval a researcher’s publish-date decision widens or narrows. I did not think about that interval at all in 2021. I do now.
The adjustments were small and boring, which is usually the sign that they are the right ones.
Since I started doing this, coordination has been smoother, and the vendor I annoyed in 2021 has, slowly, started responding to me like a normal reporter again. That took about two years and several uneventful, deadline-free reports to repair.
Coordinated disclosure is written up as a process between organizations, and it is easy to read the standards as a set of rights the researcher can assert. In practice it is a working relationship between a handful of specific, tired people, mediated by the exposure that sits on operators in the middle. The standards describe the happy path. The friction is the actual subject, and most of the friction I have caused over the years was avoidable and self-inflicted.
If you are early in doing this kind of work: the deadline is a tool, not a weapon, and the person on the other end of the alias will remember which way you used it.
The original dirtywords was a password-candidate generator. You fed it OSINT about a target (names, dates, company terms) and it produced a wordlist tuned for that target’s likely passwords, instead of throwing a generic rockyou.txt at the problem. That post is from 2021 and the tool did exactly one thing.
v2 adds a second mode that has nothing to do with passwords. It generates targeted HTTP parameter-name wordlists for brute-forcing hidden parameters and endpoints. The motivation is the same one that drove the original tool: a generic wordlist is the wrong default when you have target-specific signal sitting right in front of you. This post is a tooling note on how the parameter mode works and why I built it the way I did.
I am writing this as a design note, not a tutorial. If you maintain a fuzzing or recon tool with a parameter-discovery step, the convention-detection approach below is portable and the failure modes are probably the same shape as the ones I hit.
Parameter discovery is the step where you find the inputs an application accepts but does not advertise: the debug=true that flips on a verbose error mode, the admin flag that nothing in the UI exposes, the user_id that the endpoint reads even though the documented call only takes a token.
The standard approach is to take a large generic list (the SecLists parameter collections, or the list that ships with Arjun) and brute-force every name in it against the endpoint. The lists are good. They are also large, undifferentiated, and built for the average application rather than the one in front of you.
Two costs follow from that. The first is volume. A list of tens of thousands of parameter names, multiplied across every endpoint you want to test, is a lot of requests. On a rate-limited target, or a target where request volume is itself a detection signal, the generic-list approach is slow and noisy. The second cost is ordering. The generic list is alphabetical or frequency-ranked against a global corpus. The parameter the specific target actually accepts might be on line 14,000. You will find it eventually, but “eventually” is doing a lot of work when you are inside an assessment window.
The observation behind v2 is that the target usually tells you its own naming conventions if you look. An application written by a team that uses snake_case for everything is not going to suddenly accept camelCaseParams. An API that prefixes booleans with is_ and has_ is telling you the shape of the boolean parameter you have not found yet. A Rails backend has idioms a Django backend does not. If you can read those conventions off the target’s observable surface, you can generate a much smaller, much better-ordered candidate list.
The parameter mode runs in three stages: learn the conventions, generate candidates that match them, rank the candidates by how well they fit.
v2 harvests naming signal from whatever of the target’s surface you can give it:
swagger.json is a complete, authoritative list of the parameters the documented surface accepts, and a strong prior for the conventions the undocumented surface uses. See the OpenAPI specification for the structure v2 parses.createdAt, the input filter is more likely createdBefore than created_before.From these sources v2 derives a small convention profile:
@dataclass
class ConventionProfile:
case_style: str # "snake" | "camel" | "kebab" | "mixed"
bool_prefixes: list[str] # e.g. ["is_", "has_", "can_"]
id_suffix: str # e.g. "_id" or "Id"
common_affixes: list[str] # observed prefixes/suffixes by frequency
framework_hint: str | None # "rails" | "django" | "express" | None
vocab: collections.Counter # observed tokens by frequency
The case-style detection is the load-bearing part and it is mostly counting. If 90% of observed names match [a-z]+(_[a-z]+)+, the profile is snake. The framework hint is a weaker signal derived from telltale parameter shapes (_attributes suffixes and []-bracketed nested params point at Rails; __ lookup separators point at Django ORM filters; specific pagination param names point at common Express middleware). The hint is advisory. v2 never hard-codes a behaviour on it; it only uses it to raise the rank of framework-idiomatic candidates.
With a profile in hand, v2 builds candidates three ways:
user, account, id, and email, and the case style is snake, generate user_id, account_id, user_email, account_email, and so on. This is where most of the high-value candidates come from, because the tokens are the target’s own words.is_, and active is in the vocab, generate is_active. If the framework hint is Rails and user is a known resource, generate user_attributes and user[] forms.The output is ranked, not alphabetical. The ranking score for a candidate is a weighted sum of:
The point of the ranking is that the parameter the target actually accepts should be near the top of the list, so the brute-force finds it in the first few hundred requests rather than the last few thousand. On the assessments where I have run v2 against a baseline generic list, the convention-matched list found the same hidden parameters in roughly an order of magnitude fewer requests. That is a measured claim on a small sample, not a benchmark, and it depends heavily on how much JS or how complete a Swagger document the target exposed.
v2 writes the ranked list in the formats the downstream tools want, because nobody wants to reformat a wordlist by hand:
$ dirtywords params --js ./bundles/ --har ./session.har --out target
Learned profile: case=snake bool_prefixes=[is_,has_] id_suffix=_id framework=rails
Generated 412 ranked candidates (from 18,400 generic + 1,240 observed tokens)
Wrote:
target.txt plain ranked wordlist
target.ffuf ffuf -w input
target.arjun Arjun --wordlist input
target.json full candidates with scores
The plain list pipes straight into ffuf or Arjun. The JSON output carries the per-candidate scores so you can threshold it (only try candidates above a score, when you want to keep the request count very low) or feed it into Burp Intruder as a ranked payload set. The parameter-discovery methodology this supports is the one in the OWASP Web Security Testing Guide; v2 is a wordlist generator for that step, not a replacement for it.
Three things I tried and dropped.
Inferring types and generating values. The first design tried to infer each parameter’s type (boolean, integer, ID, enum) and emit candidate values alongside the names. This turned into scope creep. Value generation is a different problem from name discovery, the type inference was wrong often enough to be misleading, and the downstream fuzzers already handle value generation. v2 generates names only. If you need values, that is the fuzzer’s job.
Over-trusting the framework hint. An early version hard-branched on the framework hint: if it detected Rails, it generated only Rails-idiomatic candidates. That was wrong twice. Once because the detection was sometimes incorrect and the wrong branch produced a useless list, and once because real applications mix conventions (a Rails monolith with a bolted-on Express service has two conventions, not one). The hint is now advisory and only nudges ranking. The generator never excludes candidates on the strength of it.
Scraping JS at runtime. I wanted v2 to fetch and parse the target’s live JS itself. I removed it. Fetching target assets is a decision the operator should make explicitly inside the engagement scope, not something a wordlist generator does as a side effect. v2 reads JS from files you give it. Collecting those files is a separate, deliberate step.
The parameter mode is in the dirtywords main branch alongside the original password mode. The two modes share nothing except the CLI. The original password-generation behaviour from the 2021 post is unchanged; if you used dirtywords for password candidates before, that path still works the same way. The repo is at github.com/un4gi/dirtywords.
This is the same kind of small, single-purpose tooling work as the recent FAVE rebuild: take a step in an assessment workflow that defaults to a generic approach, and make it use the target-specific signal that is usually already available.
Two follow-ups are in scope. The first is a scoring-calibration pass: the current ranking weights are hand-tuned against a handful of assessments, and they should be fit against a larger labelled set of “convention profile to actually-accepted parameters” pairs. The second is an endpoint-path mode that applies the same convention-learning idea to directory and route discovery, which is the same problem one layer up. Both are notes-for-later, not commitments.
If you run a similar parameter-discovery step and want to compare convention-detection heuristics, the issues page on the repo is the right place.
]]>I pulled FAVE off the shelf last month. The 2021 introduction post described what the tool does: take a target’s detected software-version stack and return a prioritised list of applicable CVEs by querying NVD and adjacent sources. The output layer in the 2021 build was a CLI table and a JSON dump. That worked for a single-target run, but it never fit how I use the tool now, which is unattended across a small queue of assessments with results that need to land somewhere a teammate can read at the same time.
This post documents the Slack integration I added during the rebuild. I am writing it as a tooling note rather than a tutorial. If you maintain a recon tool with a similar output gap, the design decisions and the failure modes are likely the same shape as the ones I ran into.
Two reasons. The first is that the assessment workload has changed. In 2021 I ran FAVE manually, read the output table on the terminal where I had launched it, and pasted the relevant lines into whatever scratchpad held the engagement notes. In 2026 the queue runs unattended on a small VPS overnight and surfaces results into the morning. A terminal dump is no longer useful.
The second reason is downstream. As I wrote in the May cadence retrospective, the value of a CVE record in 2026 is increasingly tied to whether it lands in front of someone who can act on it within the same week. The bottleneck for me was not the CVE lookup itself, it was the gap between the lookup completing and the operator seeing the result. The Slack integration closes that gap.
Five requirements, in priority order:
These map directly onto the implementation choices below.
FAVE’s output layer used to be a single Reporter class that wrote to stdout and to a JSON file. The rebuild keeps that class for the JSON-file path but adds two new classes: SlackPublisher and AlertState. The flow is:
[ FAVE scan core ]
|
v
[ Reporter (json) ] --> /var/lib/fave/runs/<run-id>/results.json
|
v
[ SlackPublisher.from_run(run-id) ]
|
| reads: writes:
| AlertState AlertState
| results.json Slack webhook
v
[ Per-target Slack message batch ]
AlertState is a small SQLite file at /var/lib/fave/state/alerts.sqlite with one table:
CREATE TABLE posted_alerts (
engagement TEXT NOT NULL,
target TEXT NOT NULL,
cve TEXT NOT NULL,
first_posted TEXT NOT NULL,
PRIMARY KEY (engagement, target, cve)
);
That is the entire deduplication mechanism. A row is inserted the first time a (engagement, target, cve) triple gets posted, and subsequent runs that produce the same triple skip the post. The decision to make this engagement-scoped rather than global is intentional: across engagements, the same CVE is a fresh signal, because the operator who reads the message has different context.
FAVE is Python 3.11. I considered using the official slack-sdk package but ended up with a thin requests-based wrapper, because the integration only needs one Slack endpoint: an incoming webhook. The advantages of slack-sdk (token rotation, Block Kit type hints, OAuth helpers) do not apply when you are using a webhook URL.
The webhook config lives in /etc/fave/slack.toml:
[engagement.acme-q2-2026]
webhook_url = "https://hooks.slack.com/services/T0XXX/B0YYY/abc123..."
channel_name = "#sec-acme-q2"
severity_threshold = 7.0
[engagement.internal-recon]
webhook_url = "https://hooks.slack.com/services/T0XXX/B0ZZZ/def456..."
channel_name = "#sec-internal-recon"
severity_threshold = 4.0
The severity_threshold is a per-engagement floor on the CVSS base score below which findings are written to the JSON file but not posted to Slack. For the internal-recon engagement, the operator wants medium-and-up. For acme-q2-2026, the operator wants high-and-critical only and reviews the JSON output separately for the rest.
The publisher itself is short. The relevant body is:
class SlackPublisher:
def __init__(self, engagement_cfg, state: AlertState):
self.cfg = engagement_cfg
self.state = state
def publish_findings(self, run_id: str, findings: list[Finding]):
new_findings = [
f for f in findings
if f.cvss_base >= self.cfg.severity_threshold
and not self.state.already_posted(
self.cfg.engagement, f.target, f.cve
)
]
if not new_findings:
return
for batch in chunked(new_findings, 25):
payload = self._build_block_kit(batch, run_id)
self._post_with_retry(payload)
for f in batch:
self.state.mark_posted(
self.cfg.engagement, f.target, f.cve
)
Three things in this code are non-obvious and worth calling out.
The Slack message-size limit for an incoming webhook is 40,000 characters of payload. A single Block Kit message can carry roughly 50 sections before it gets unwieldy. I batch in chunks of 25 to leave headroom and keep each posted message readable. The chunking is a chunked() helper that yields fixed-size slices of an iterable.
The state.mark_posted call happens after the post returns 2xx. If the post fails, the state is not written, and the next FAVE run will retry the same finding. This is the correct posture for an alerting integration: a finding that has not actually surfaced to the operator should be retried, not silently marked as delivered.
_post_with_retry uses an exponential backoff with jitter (0.5s, 1s, 2s, 4s, 8s) for transient errors (HTTP 5xx, connection-reset). On a 429 Retry-After, it sleeps for the duration the server requests and then continues. On any 4xx other than 429, it gives up and raises, because a 400 from Slack means the payload is malformed and retrying will not help.
I use Slack Block Kit rather than plain text. The relevant blocks per finding are a Header (target hostname), a Section with severity-coloured indicator, a divider, and a context block with the source file link.
A rendered finding looks like:
─────────────────────────────────────────
acme-app01.internal
─────────────────────────────────────────
CVE-2024-39882 CRITICAL CVSS 9.8
Authentication bypass in Acme Web v3.1.2
→ NVD record
─────────────────────────────────────────
Run: fave-2026-05-16-acme-q2 · results
The severity tag is a unicode emoji-free indicator. Slack messages do not need emojis to be readable, and operator feedback on the first pass was that emoji-heavy alerts produce inconsistent rendering across desktop and mobile clients. Critical findings get a leading ■ and [CRITICAL] text label. The colour comes from the Block Kit attachments.color field on the surrounding container, which Slack renders as a left-edge bar. Red for critical (CVSS >= 9.0), orange for high (>= 7.0), grey otherwise.
The “results” link goes to a per-run static HTML report that FAVE writes alongside the JSON file. This is the same change the cadence post argued for at the institutional level: an alert is more useful when there is a primary-source artefact one click away.
Slack’s rate-limit documentation is precise: webhook integrations are tier-1, which is “one message per second per webhook, with short bursts allowed”. The Retry-After header on a 429 is the authoritative source for how long to back off.
I tested this with an artificial 200-finding run against a private webhook. With batching at 25 per message, that is 8 messages, and the integration completes in well under 30 seconds without ever hitting 429. The retry path exists for unexpected upstream issues, not for the well-behaved case.
For larger runs, batching at 25 with the 1s pacing gives a clean linear scale. A 1,000-finding run would take ~40 messages, ~40 seconds. I have not yet had a run that produces 1,000 unique findings post-deduplication, so the upper bound has not been stress-tested in production conditions.
Three things I tried that did not survive review.
The first design used a parent “run summary” message and posted each finding as a threaded reply. The intent was a tidy Slack channel where each FAVE run was one thread the operator could collapse.
The problem is that incoming webhooks cannot post to a thread. They can only post into a channel. Threaded replies require either a bot token (chat.postMessage with thread_ts) or a Slack app. Neither is appropriate for this use case, since the webhook URL is the only artefact the engagement-channel admin gives the integration.
I went back to flat-channel posts, which is what works with a webhook.
I tried rendering the CVSS vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) as a stand-alone Block Kit section per finding, with each component labelled. This was visually correct but doubled the message length and pushed the 25-per-batch chunking down to 12. Operators told me they did not read past the base score on most findings and would click through to NVD for the vector when they needed it.
The vector is now in a single line in the context block at the bottom of each finding, not a stand-alone block. Operators get the score prominently and the vector available without claiming the visual budget.
I wanted the integration to detect when the engagement channel was archived or the webhook had been revoked, and degrade gracefully (write a warning to a log and stop trying for that engagement). Slack webhooks return a 404 when the URL is no longer valid, but they also return a 404 in some transient cases, and I did not find a reliable signal that distinguished permanent revocation from a transient issue.
The current behaviour is: three consecutive 404s for a given webhook causes the integration to log a CHANNEL_PAUSED event for that engagement, but FAVE keeps trying on the next run. The decision to actually pause needs an operator. Automating it would have produced false-negative pauses that cause findings to silently stop reaching the channel.
The Slack integration is in the FAVE main branch. It is enabled by default if /etc/fave/slack.toml exists. The 2021 FAVE introduction post is still the canonical reference for what the tool does at the scan-and-correlate level; this post is the canonical reference for the output layer in 2026.
If you run a similar tool and want to compare notes on the deduplication state shape or the Block Kit chunking decisions, the FAVE repo issues page is the right place.
Two follow-ups are already in scope.
The first is a Block Kit version of the per-run static HTML report that the “results” link currently goes to. The HTML report is a server-rendered page; the next iteration will let the operator open the same report inside a Slack canvas, which removes a context switch that several operators have flagged.
The second is a webhook-signature-verification path so FAVE can accept inbound Slack events (a slash command, for example, that re-queries a host from inside the channel). That is a larger change because it requires FAVE to expose an HTTP endpoint to Slack, and the threat model on that endpoint is not the same as the threat model on an outbound webhook. The current scope of this post is the outbound side only.
The cadence between this rebuild and the next post will be roughly four weeks, matching the cadence in the publishing notes.
]]>In April I posted a five-year retrospective covering the institutional changes around vulnerability disclosure since the 2020 Quest Policy Authority advisory. That post covered the structural side: NVD enrichment, the CVE program funding scare, the EU Cyber Resilience Act, the rise of the KEV catalog. It did not look closely at the question that operators ask first: when a researcher discloses something, how long does it actually take for a patch to appear?
This post tackles that narrower question: has vendor patching cadence changed between 2020 and 2026?
The short answer is yes for some vendors, no for most, and the gap between the two has widened. There is no single industry cadence to quote. There are at least three, and they have diverged.
I draw on three sources below. None of them is a complete dataset.
Before any numbers, a definition. The full disclosure pipeline has at least four measurable intervals.
| Interval | What it measures |
|---|---|
| Time-to-acknowledge | Researcher first contact, vendor confirms receipt and triage |
| Time-to-fix | Acknowledge, code change merged, internal build available |
| Time-to-ship | Internal build, GA release reaching customers |
| Time-to-disclose | Researcher coordination window, public advisory |
Public conversations about cadence usually conflate these. A vendor who acknowledges within a day but ships a year later is not the same as a vendor who responds in two weeks and patches in three. Both are common. Both look like “the vendor responded” in casual reporting.
In the rest of this post I will be specific about which interval I am citing. The KEV catalog effectively measures something else again: time from public CVE to documented exploitation, and then a separate federal-agency remediation deadline. I will treat that as its own thing.
The biggest change since 2020 is that more vendors now publish a security policy page at all. In 2020, finding a vendor’s coordinated disclosure SLA usually meant emailing security@ and waiting to see what came back. In 2026 the larger vendors have committed something to writing. Whether the document is honored is a separate question.
A short, non-exhaustive comparison of what large vendors say about their own cadence:
| Vendor / project | Public cadence commitment | Where to verify |
|---|---|---|
| Microsoft | Monthly Patch Tuesday for non-emergency fixes; 90 days as the default coordinated disclosure window before independent publication; out-of-band releases for actively exploited issues | Microsoft Security Update Guide and the MSRC blog |
| Apple | Fixed-version-only model: security fixes ship in the next supported OS update, not as targeted backports; security content documented per release | Apple security releases |
| Linux kernel | No formal SLA; most fixes land within days of report when the report is well-formed; coordinated embargo via linux-distros for issues with cross-distro impact | Kernel maintainer correspondence is largely public on lkml |
| Major cloud / hyperscale | Internal first, customer-facing CVEs after mitigation; a meaningful share never receive a public CVE because the customer has no remediation action | |
| Google Project Zero (researcher side, for context) | 90-day disclosure window plus optional 30-day grace if a fix is in flight; immediate disclosure for actively exploited issues | Project Zero policy |
| Bug-bounty platforms | No platform-wide SLA; per-program. Most published programs commit to triage within 72 hours and a fix-or-update target somewhere between 30 and 180 days | HackerOne directory, Bugcrowd directory |
Pre-2020, almost none of this was written down in a way a researcher could cite. The improvement is real, even if the actual time-to-fix has not always followed.
The gap to keep in mind is between what a vendor publishes and what a researcher experiences. Microsoft’s published target is 90 days. The actual time from acknowledgment to a Patch Tuesday release for routine findings often runs longer, because routine findings get queued behind whatever is currently being exploited. Apple’s fixed-version-only model is honest but it means a fix landing in iOS 19.x reaches no users still on iOS 18, by design.
CISA’s Known Exploited Vulnerabilities catalog is the closest thing the industry has to a public, structured cadence dataset. It is also commonly misread, so a quick note on what it does and does not measure.
KEV records do not directly track vendor patching cadence. They track exploitation. A KEV entry includes a CVE ID, the date CISA added it to the catalog, and the federal-agency remediation deadline (dueDate). The implicit assumption is that any KEV-listed CVE has a vendor patch available, since federal agencies are required to remediate by the due date. That is mostly true.
What you can derive from KEV records is two narrower numbers.
dueDate 14 to 21 days after the KEV addition, with rare extensions for harder cases. This is a hard deadline for FCEB agencies and a strong signal for everyone else.KEV has grown from roughly 300 entries at launch in late 2021 to around 1,500 entries by mid-2025. That growth is partially a backlog catch-up, not a real-time exploitation count. CISA’s Binding Operational Directive 22-01 pulled in pre-existing exploited issues during the catalog’s first 18 months.
For our cadence question, the useful KEV signal is this. Once a CVE is on KEV, defenders behave as if a patch is available within two weeks. That is the pressure-cooked, accelerated branch of the cadence story. It applies to about one percent of all CVEs.
The 2020 Quest UC report was not a one-off. I have continued to file disclosures since then. The cadence I see is heavily shaped by which class of vendor the issue lands with, and to a lesser extent by whether the vendor runs a structured bug-bounty program.
A representative sample of patterns I have observed across follow-ups since the Quest writeup, lightly anonymized where the disclosures are not yet public:
| Vendor class | Acknowledgment | Fix shipped | Coordination |
|---|---|---|---|
| Fortune-500 software vendor with formal PSIRT | Within 48 hours, every time | 30 to 90 days for non-critical findings; faster for critical | Professional, predictable |
| Mid-market enterprise vendor running HackerOne or Bugcrowd | Within 72 hours, usually | 60 to 180 days, depending on roadmap pressure | Triage is sharp; fix scheduling is opaque |
| Mid-market enterprise vendor without a bug-bounty program | 1 to 4 weeks, often after a follow-up email | Variable. Some patch in weeks. Some go silent and ship a fix without notifying me. | Frustrating, similar to 2020 |
| Small or end-of-life product | “We will look into it” or no response | “End of life, no patch” or no response | Identical to 2020 |
| OSS project with active maintainers | Within hours when the report is well-formed | Days to a few weeks | Faster than commercial vendors |
The absolute numbers are not the interesting story. The shape is. The Fortune-500 PSIRT process and the OSS-with-active-maintainers process are noticeably faster and more predictable than they were in 2020. The middle band is the same. The long tail is the same or worse.
The single most consistent accelerator I have seen is presence on KEV. On the rare occasion a finding I disclosed went on to be confirmed as exploited and added to KEV, the vendor went from “we will look at this in next quarter’s planning” to “we are shipping the fix this week” inside a few days. That is not a coincidence. KEV listing converts a vendor-internal scheduling problem into a customer-relations problem.
The second most consistent accelerator is a structured bug-bounty program. Not the bounty payout itself, the program’s published triage SLAs and the visible-from-outside report queue. A vendor whose security team has an externally-readable backlog has a different incentive structure to a vendor whose backlog lives inside JIRA.
A few things look identical to 2020.
Three implications, which are the practical lift-out from all of the above.
For researchers. Your leverage matters. A bug-bounty program raises the floor on triage speed and lowers the variance on outcomes. KEV listing, when it happens, raises the ceiling on patch speed by an order of magnitude. Cold-emailing a mid-tier vendor without either of those signals in 2026 looks essentially like cold-emailing the same vendor in 2020. Plan accordingly.
For defenders. Do not assume an industry-wide patching cadence. Plan for the mid-tier case unless you have specific evidence that a CVE is on KEV or that the vendor’s PSIRT has shipped recently. A patched build existing in the vendor’s release engineering queue is not the same as a patched build on your customer fleet.
For policy. The KEV catalog has worked well at compressing the patching cycle for the narrow set of actively-exploited vulnerabilities. It has not changed the cadence for the much larger set of routine findings. The CRA, when it begins to bite for products sold into the EU, is the next plausible accelerator for the middle band. We will see how that goes.
The 2020 Quest disclosure took seven days from first email to public posting. The product was unpatched and stayed unpatched. If I disclosed an equivalent finding against an equivalent product in 2026, the result would be effectively the same. The infrastructure around it would look more modern. The patch outcome would not.
In December 2020 I published an advisory covering thirteen vulnerabilities in Quest Policy Authority for Unified Communications. The product had been end-of-life for over seven years at the time of the report. Quest acknowledged the findings and confirmed no patches would be issued. The disclosure went public the same day Quest closed the case.
This post is a five-year retrospective. I am not revisiting the technical findings. The vulnerabilities are still listed in NVD, the product is still unsupported, and the recommendations from the original advisory have not changed. What has changed is the broader ecosystem around how a researcher discloses, how a vendor responds, and how a downstream operator becomes aware of a vulnerability they need to patch. In late 2020 most of the institutional plumbing that exists today did not. This post documents what is different now, and asks the simple question: if I disclosed those same findings in 2026, would the outcome be any better?
| Product | Quest Policy Authority for Unified Communications |
| Affected version | 8.1.2.200 |
| Vulnerabilities reported | 13 (CVE-2020-35203 through CVE-2020-35206, CVE-2020-35719 through CVE-2020-35727) |
| Vendor response time | Within 24 hours on first contact |
| Patch status | None. End-of-life product. |
| Public disclosure | Same day as vendor closure of the case |
The disclosure timeline ran from December 9 to December 16, 2020. Seven days from first email to public posting. Quest’s communication was professional throughout. The reason no patch arrived was not vendor neglect, it was vendor honesty about the product lifecycle.
Five things, in roughly the order they happened:
| Date | Change | Effect on the disclosure pipeline |
|---|---|---|
| 2021-11 | CISA published Binding Operational Directive 22-01 and the Known Exploited Vulnerabilities catalog | Federal agencies must remediate listed CVEs by hard deadlines. The catalog is now widely cited as a downstream prioritisation source by private organisations as well. As of 2025 it covers roughly 1,500 entries. |
| 2023-11-01 | FIRST.org published CVSS v4.0 | New base, threat, environmental, and supplemental metric groups. Replaces CVSS v3.1 as the recommended scoring framework. Adoption in NVD records is still partial as of 2026. |
| 2024-02-12 | NVD began slowing CVE enrichment (CPE matching, CVSS scoring, references). Backlog grew past 18,000 CVEs in 2024. | Researchers and downstream consumers can no longer assume that an NVD record will arrive enriched within days. In April 2026 NIST formally changed policy to enrich only the subset of CVEs meeting risk criteria, leaving the rest as raw records. |
| 2024-12-10 | The EU Cyber Resilience Act entered into force | Manufacturers of products with digital elements sold in the EU must support security updates for a defined period and handle vulnerabilities throughout the product lifecycle. Reporting obligations apply from 2026-09-11. Full obligations from 2027-12-11. |
| 2025-04-16 | The MITRE CVE program funding lapsed and was rescued at the deadline by an 11-month CISA contract extension. The CVE Foundation was launched in response. | The institutional foundation that researchers depend on to assign CVE IDs is now visibly contingent. The Foundation exists to provide a non-governmental backstop. |
These are the structural changes. There are also softer shifts in researcher practice that are harder to date precisely. More researchers now post first to a personal blog or GitHub gist and assign a CVE later. More vendors run formal bug bounty programs. More downstream consumers track vulnerability databases directly rather than waiting for NVD enrichment.
Probably yes for the technical content, but the surrounding context would be different in three concrete ways.
In 2020 I submitted to Quest’s security inbox. MITRE assigned CVE identifiers within days. NVD enriched the records (CPE strings, CVSS vector, references) within roughly two weeks. By 2024 that pipeline had broken in a way that has not fully recovered. If I disclosed thirteen CVEs against an end-of-life Quest product in 2026, only the subset NIST classified as high-risk would receive prompt enrichment. The rest would sit as raw CVE records. For an attacker, that is meaningful: less context for downstream tooling, less visibility for defenders relying on automated CPE matching.
The ironic effect is that the Quest 2020 disclosure was easier to document and act on than an equivalent 2026 disclosure would be. The bottleneck has moved from vendor patch availability to public-record quality.
The Quest response in 2020 was that the product had been unsupported for over seven years and no patch would be issued. That is a defensible position for a US-headquartered vendor selling a product that has reached genuine end-of-life and was never relabelled as supported.
Under the EU Cyber Resilience Act, this position becomes harder to maintain for products sold into the EU after the regulation applies. Manufacturers must define a support period, handle vulnerabilities during it, and document the security update lifecycle. The Quest UC product would not be subject to the CRA retroactively, and Quest may not have continued to sell into the EU at the time of disclosure. But for a comparable product on sale in 2026 and beyond, the answer “no patch, end of life” is a regulatory question, not just a customer-relations question.
In practice this means EU researchers reporting issues against EU-sold products now have a clearer escalation path when a vendor declines to patch. ENISA reporting obligations from September 2026 onwards will further shift the disclosure paperwork.
In 2020 a researcher disclosed, NVD enriched, and downstream operators decided what to patch based on CVSS and their own risk assessment. By 2026 the practical question for many defenders is not “what is this CVE’s CVSS score” but “is it on KEV”. That is a narrower question and a more actionable one.
The Quest UC vulnerabilities would not have made KEV. There is no public evidence of exploitation, the affected product population is small, and the product is end-of-life. CISA’s listing criteria reasonably exclude this category. The same logic applies to most XSS, CSRF, and SSRF findings in niche enterprise software. KEV is a useful signal precisely because it is narrow. The downside is that the CVE-but-not-KEV middle band has become harder for defenders to triage.
The 2020 advisory recommended decommissioning the product. That recommendation still holds, and the absence from KEV does not change it.
For comparison with the 2020 timeline, here is what the same disclosure flow looks like now:
| Step | 2020 | 2026 |
|---|---|---|
| Initial vendor contact | security@vendor.com | Same. Some vendors now run a HackerOne or Bugcrowd program instead. |
| Triage | Vendor confirms within days | Variable. Established vendors meet the same SLA. Smaller vendors have moved to “we will respond when we can”. |
| CVE assignment | Vendor or MITRE | Vendor CNA where one exists, MITRE root otherwise. The CVE Foundation now provides a contingent backstop. |
| NVD enrichment | Within ~2 weeks | Variable. Top-tier risk: enriched. Everything else: raw record only. |
| KEV consideration | N/A | Only if active exploitation evidence exists |
| Public disclosure | After patch or after coordinated period | Same. 90 days remains the de facto norm. |
| Defender pickup | NVD feed or vendor advisory | NVD feed (with caveats above), KEV catalog, vendor advisory, vulnerability-management vendors that re-enrich raw CVEs |
The end-to-end time from researcher-finds-bug to defender-aware-of-bug is not dramatically different. What is different is how much context arrives with the CVE record, how confidently a defender can rank it against thousands of others, and how much regulatory machinery now applies to the vendor.
The Quest UC disclosure was a small piece of routine vulnerability research. Five years later the same routine still works, but the surrounding ecosystem has had a turbulent half-decade. The CVE program nearly went dark for a week in April 2025. NVD has effectively conceded that it cannot enrich every record. The EU has decided that “end-of-life, no patch” is no longer a complete answer for products sold into its market. CISA has pulled the most operationally important subset of CVEs into a separate catalog with hard deadlines.
For researchers, the practical guidance is unchanged. Document carefully. Coordinate with the vendor. Cite primary sources. Publish when the responsible-disclosure window closes. The infrastructure around these steps is less stable than it was in 2020. Plan accordingly.
For organisations still running Quest Policy Authority for Unified Communications in 2026, the original recommendation stands. The product is unpatched and unsupported. Decommission it.
In late March / early April 2021 my application to Synack was approved and I gained access to the platform. The first few days were spent fumbling through menus and figuring out how to navigate. After talking with some of the more experienced members I was told quickly that I needed a mission bot if I wanted any chance of grabbing missions. One member shared their bot with me and for several months I was able to claim multiple missions a day without issue.
Eventually changes to the platform started impacting how that bot worked with the mission API. My access to missions began diminishing as I was constantly disconnected or beaten to claims by an increasingly prevalent number of bots. Around this time I was learning Go, and decided to further that learning by building a custom mission bot for the Synack API.
I released version 1.0.0 in October 2021 with minimal functionality: just enough to claim missions and onboard to targets. Since then I had spent significant time on improvements aimed at automating the routine parts of mission work.
With Synack’s release of the Mission Trust Wallet feature, I no longer have the time to spend on missions for the now reduced compensation. Rather than let the bot sit unused, I am releasing v2.0.0 to the community.
Frequent session timeouts on the Synack platform made automated login a priority. Two-factor authentication was the main blocker for automation. The authy Go library handled the 2FA flow cleanly, and the rest of the login process was straightforward to script after that.
The bot was claiming missions, but I was occasionally going a full day without checking whether anything had been claimed. I added notifications using the discordgo package. The current implementation only emits notifications for claimed missions, but the same plumbing should make broader command-and-control functionality straightforward to add later.
v2.0.0 includes scaffolding for mission templates that pre-populate fields when a mission is claimed. Used properly this should reduce write-up time substantially.
After claiming multiple missions for a target that turned out to be non-functional more than once (those who know, know), I implemented a blacklist. Any target name on the blacklist is skipped during the claim flow.
The bot was still a work in progress when I shelved active development. There are hints in the source of features that were partway in for anyone interested in continuing the work.
The repository is at github.com/un4gi/mBot. Read through the code and configure the default settings before running. mBot is intended to be invoked with arguments as documented in the README. The default check-in interval is set to one second deliberately, as a deterrent against running it without first reading what it does.
This bot was built and used by me on the Synack platform. Synack’s terms of service and acceptable use policies have changed over time. If you fork or run this code, the responsibility for compliance with whatever the current rules are at the time you run it is yours, not mine. The original code is provided as-is for reference and as a starting point for further work.
]]>Traditional VPNs give users full network access once connected. Authenticate once, get a tunnel, access everything. This is fundamentally incompatible with zero trust principles, and it is why organizations are moving to Zero Trust Network Access (ZTNA).
ZTNA flips the model: verify every request, grant access only to specific applications, and never trust the network.
The core concept is simple:
The user never gets “network access.” They get application access through an encrypted tunnel to a broker that validates every request.
When comparing zero trust network access providers, focus on these areas:
Identity integration - Does it work with your existing IdP (Azure AD, Okta, Ping)? Does it support SAML 2.0 and OIDC? Can it enforce MFA natively or through your IdP?
Device posture assessment - Can it check OS version, patch level, antivirus status, disk encryption, and firewall state? Can you create custom posture checks? How frequently does it re-evaluate?
Application support - Does it support web apps, thick client apps, SSH, RDP, and custom TCP/UDP protocols? Some ZTNA solutions only work well with HTTP-based applications.
Deployment model - Agent-based (installed on endpoints) vs. agentless (browser-based). Agent-based provides more control and supports non-web protocols. Agentless is easier to deploy for contractors and BYOD.
Performance - Where are the provider’s points of presence? Latency matters. A ZTNA solution that routes all traffic through a single data center across the continent will frustrate users.
Logging and visibility - Detailed session logs including user, device, application, duration, and bytes transferred. Integration with SIEM platforms.
The major categories of ZTNA providers:
Pure-play ZTNA:
SASE-integrated ZTNA:
Identity-vendor ZTNA:
Open source:
ZTNA is not a silver bullet. It secures remote access to applications, but it does not replace:
Think of ZTNA as replacing your VPN concentrator, not your entire security stack. It is one component of a zero trust architecture, not the whole thing.
Start with your highest-risk remote access use cases - typically admin access to production systems and third-party/contractor access. These are the scenarios where traditional VPN is most dangerous and where ZTNA provides the most immediate value.
]]>Most organizations are not fully in the cloud. They run hybrid environments with workloads split between on-premises data centers and one or more cloud providers. This creates a security architecture challenge that neither traditional network security nor cloud-native security approaches handle well on their own.
The attack surface spans both environments, and the gaps between them are where things go wrong.
In a hybrid environment, identity is your primary security control. Network perimeters are meaningless when your users access both on-prem Active Directory resources and cloud services.
Federation is mandatory. Use SAML 2.0 or OIDC to federate your on-prem identity provider with cloud IAM. Azure AD Connect for Microsoft environments, or a third-party IdP like Okta for multi-cloud.
Key principles:
The connectivity between on-prem and cloud is your highest-risk attack path.
VPN or Direct Connect/ExpressRoute for connectivity - never route hybrid traffic over the public internet. Use dedicated connections where possible.
Segmentation model:
On-Prem DC Transit VPC/VNet Workload VPCs
+-----------+ +--------------+ +------------+
| Internal |<----->| Firewall/IDS |<------->| Production |
| Network | VPN/ | Route tables | +------------+
| | DC | NAT gateways | | Staging |
+-----------+ +--------------+ +------------+
| | Dev |
+-----+-----+ +------------+
| Shared Svc |
| (DNS, AD) |
+-----------+
Data in transit: TLS everywhere, including between internal services. Mutual TLS (mTLS) for service-to-service communication in high-security environments.
Data at rest: Use cloud-native encryption (AWS KMS, Azure Key Vault) for cloud workloads. The critical decision is key management - who controls the keys?
Centralize your security monitoring. Ship cloud logs (CloudTrail, Azure Activity Log, VPC Flow Logs) to your on-prem SIEM, or use a cloud-native SIEM that can also ingest on-prem data. The worst outcome is two separate security teams looking at two separate dashboards with no correlation between them.
Build detection rules that span both environments. An attacker who compromises an on-prem system will pivot to the cloud, and vice versa.
]]>