The advisory feed

The advisory feed is a set of public files that the vendor builds and signs. Every install that fetches it downloads the same bytes, and the files carry nothing about any install. An early access install does not download the feed yet; this page describes the design, and the Vulnerabilities page lists what is in the product today.

What an install downloads

• First the delegation and the head of the feed, about 4 KiB.
• Then, only if the head changed, the content-addressed files the head names: new advisories, withdrawals and the facts that rank them.
• Each request is a plain GET of a fixed path, with a fixed user agent that carries no version, no cookie and no query string, and no conditional header.
• Each fetch uses a fresh connection, with session resumption and keep-alive off, so one fetch cannot be linked to the next.
• The install reads this site’s copy first and the vendor’s bucket in AWS second, compares the two heads, and keeps only files that verified.

How often

A keeper chooses. The design’s default is live: every 15 minutes, with a random delay of up to five minutes, the head only unless it changed. A keeper can choose hourly, daily or on request. With on request, the console’s “Check now” button is the only trigger. If the vendor cannot be reached, the install keeps matching on what it holds and says how old that is.

The target is a finding on the page within the hour of an item reaching the feed, for installs on the live schedule. That target is about the page. Notices follow once the rules leave shadow on that install.

The signatures

• Two feed signatures. Every head and snapshot carries two signatures made by keys held in separate custody: the builder’s key in one vendor AWS account, and a co-signer’s key in a second account that trusts nothing in the first. The co-signer rebuilds the machine-sourced records itself and signs only if they match byte for byte.
• The curator signature. An advisory a curator writes carries its own signature, by a curator key from the release root. An install accepts a curated record only with that signature, so the two feed keys, alone or together, cannot mint one.
• The delegation. A small file signed by the release keys names which feed keys are active. It is renewed every three weeks. A lapsed delegation stops an install accepting new heads, and the console says why.

The feed can add advisories, ranges, exploitation facts and lifecycle dates, and withdraw or narrow them. It cannot change code, rules, policy, authority or anything an install does. Machine sources run around the clock. A curator works in working hours, and the feed status page publishes the measured time from a source’s post to the feed. The site makes no response-time promise.

What each host can see

Without any logging switch, Cloudflare, which serves this site’s copy, and AWS, which serves the vendor’s bucket, each see the source address of every request and its time. A fetch is designed to run outside any VPC, so the address comes from the AWS region’s shared Lambda address pool, which reveals the region. Cloudflare’s own analytics keep requests per request.

This site counts nothing and writes no log line for the feed files under /feed/. The status page at /feed is an ordinary page and is counted like any other page. The vendor’s bucket is defined with no access log and no record of reads, so the vendor stores nothing about fetches. A keeper who wants less chooses hourly, daily or on request. A “Check now” also shows that someone asked at that minute.

The public pages for the items the feed carries are at /advisories. Nothing is sent from your install to the vendor’s site except the request for a public file.