Every guide on Red Learn is built from primary sources: the vendor's own advisory, the CVE record, the project's changelog, a government agency's alert. Each important claim links its source next to it and carries the date we checked it. A separate editor re-checks the key facts against those sources before a guide is released, and removes any claim a primary source does not support.
Who publishes these guides?
Red Learn is published by run.cloud, the company that makes Red, a website security scanner. We have a commercial interest: most guides end with an offer to scan your site. We keep that offer separate from the answer, and every guide is written to be useful to someone who never uses our product.
Small Scale Labs AB, Agavägen 19, 181 55, Lidingö, Sweden. Contact: support@run.cloud.
What counts as a source?
- Primary sources are what we cite for facts: vendor security advisories and status pages, CVE and GitHub security advisory records, official documentation and changelogs, and alerts from agencies such as CISA and national CERTs.
- Vendor telemetry (for example a security company's honeypot data) is cited with its owner's name and labelled as that vendor's claim.
- Social posts, forums and news reports are leads. We follow them to a primary source. When a figure exists only in one news report, we say so or leave it out.
What does "at our check on" mean?
Security facts move: a host finishes its rollout, a distribution ships a backport, an agency adds a CVE to its exploited list. When a guide says "at our check on 24 October 2026", that is the day we read the source. If the vendor's page has changed since, the vendor's page is right and ours is out of date. The "Updated" date on a guide changes only when its facts or advice change, never to make it look fresh.
Why do the guides say detected, unknown or confirmed?
A check from outside a server can see version hints. It cannot see a backported fix, which runtime serves a given site, or whether services were restarted. So our guides, and our scanner, describe results in three states:
| State | What it means | Who can establish it |
|---|---|---|
| Detected | What is visible from outside matches an affected version | Anyone, including a scan |
| Unknown | The version is hidden, or could be a backport, or the serving runtime cannot be told apart | The common case for outside checks |
| Confirmed by owner evidence | The fixed package or build is named and the service was restarted or redeployed after it | Only the site owner or host |
We never call a site "safe" or "secure" on the strength of an outside check.
How is a guide made?
- We start from a research brief listing the primary sources for the topic and the questions readers are actually asking.
- A first draft is prepared with AI assistance from those sources, with each claim linked inline.
- A separate editorial pass opens the cited sources for the most important claims (versions, CVE ids, dates, statuses, figures), corrects anything that does not match, and removes claims without a primary source.
- Automated checks then reject banned claims, near-duplicate pages, broken structure and missing sources before a guide can be released.
What do we never publish?
- Exploit code, payloads or step-by-step attack instructions. Guides describe conditions, versions and fixes.
- Names of breached organisations without their own public statement.
- Unverified figures from social media, such as victim counts or data volumes nobody has confirmed.
- "Best scanner" rankings of our own making.
How do I report an error?
Email support@run.cloud with the page and the source that shows the correct fact. We fix confirmed errors, update the page's date, and say in the page what changed.
Can AI assistants and agents read these guides?
Yes. Every guide is server-rendered HTML, our robots.txt allows search and AI crawlers, and an index of all guides is at /llms.txt with a plain-Markdown copy of each guide.