What to Consider When Using isopenbsdsecu.re as a Source on OpenBSD Security

isopenbsdsecu.re is a single-purpose reference page that hosts the slides and video of a 2019 conference talk, "A systematic evaluation of OpenBSD's mitigations," presented at 36c3 on December 29, 2019. It is useful as a pointer to a structured third-party evaluation of OpenBSD's exploit mitigations, but it is not an official OpenBSD statement, not a current audit, and not a general verdict on whether OpenBSD is "secure." Treat it as one dated input among several, and read the slides and video together rather than relying on the page's title question.

What the site actually contains

The page's own text is minimal: a heading asking "Is OpenBSD secure?" and a note that the slides and video from the 36c3 talk are available, with a fallback message that the site works even with JavaScript disabled. There is no summary of findings, no methodology write-up, and no update log on the page itself.

That means the site functions as an index, not an analysis. The substance lives in the linked slides and recording. If you cite "isopenbsdsecu.re says OpenBSD is/isn't secure," you are citing a title, not a conclusion.

Check the date before you rely on it

The talk was given on December 29, 2019. OpenBSD, like any operating system, changes its mitigation set over time: features get added, defaults change, and older protections get reworked or replaced. A 2019 evaluation describes the state of the code and the threat model as the speaker assessed them then.

Practical implications:

• For historical or methodological questions — how someone systematically evaluated OpenBSD mitigations, what categories they used, what they found at the time — the material is appropriate and citable with the date attached.
• For current claims — "OpenBSD does/doesn't have mitigation X today" — verify against current OpenBSD documentation, release notes, and source. Do not carry a 2019 finding forward as a present-tense fact.
• When writing, always attach the year: "a 2019 systematic evaluation of OpenBSD's mitigations (36c3)" rather than "an evaluation shows."

Understand the scope: mitigations, not "security"

The talk's subject is OpenBSD's mitigations — the hardening techniques intended to make exploitation harder. That is a narrower question than "is OpenBSD secure," which also depends on code quality, default configuration, privilege separation, patch cadence, and how the system is deployed.

Two consequences:

1. A finding that a particular mitigation is weak, incomplete, or bypassable does not by itself establish that the system is insecure in practice.
2. A finding that mitigations are strong does not cover configuration, administration, or non-mitigation bugs.

When you use the material, state the scope explicitly: "this evaluates mitigation measures," not "this evaluates OpenBSD's overall security."

It is a third-party evaluation, not project documentation

The site is independent of the OpenBSD project. That is not a reason to dismiss it — external evaluation is valuable precisely because it is independent — but it changes how you weigh it:

• Use it for: an outside perspective, a structured checklist of what to examine, and specific technical claims you can then verify in the source tree or official docs.
• Don't use it for: authoritative statements of what OpenBSD supports, recommends, or guarantees. For those, go to the OpenBSD project's own documentation and release materials.
• Watch for: claims that are presented as general conclusions but rest on specific test conditions. Check the slides for the assumptions behind each result.

How to read the slides and video together

The page points to both formats, and they carry different information. The slides hold the structured claims, tables, and terminology; the video carries the speaker's caveats, qualifications, and answers that often do not appear on slides.

A workable approach:

1. Open the slides first and note each claim and the condition it depends on.
2. Watch the corresponding segment of the video for the speaker's stated limits and any audience Q&A that qualifies a result.
3. For any claim you intend to repeat, check it against current OpenBSD source or documentation before publishing.
4. Record the source as: talk title, conference (36c3), date (December 29, 2019), and the specific slide or timestamp.

If JavaScript is disabled, the page states the slides and video remain accessible — so a script-blocked browser is not a barrier to the material itself.

A quick decision guide

The short version: use isopenbsdsecu.re to find and cite a specific, dated, third-party mitigation evaluation, keep its scope and year attached to every claim you draw from it, and confirm anything present-tense against current OpenBSD sources.