Security Analyzer

The Security Analyzer at https://app.rotorlab.app/security assesses your aircraft against the UAS Security Verification Standard (UASVS), an open, vendor-neutral standard (0.1) published at uasvs.org, free to read and dispute. Every requirement carries a permanent identifier, an assurance level and a published rule, so any verdict here can be reproduced by anyone holding the same log bytes and the same version of the standard. Reach for it when a client, an insurer or a procurement officer asks how your aircraft are configured, or before they do.

It reads the same flight logs as the Log Analyzer: ArduPilot dataflash (.bin), MAVLink telemetry (.tlog) and PX4 ULog (.ulg), with the format detected from the file's bytes rather than its name.

What you need#

The Security Analyzer requires an account with the Security Analyzer add-on enabled, or a plan that includes it. Without it, the page shows a The Security Analyzer is an add-on notice with a link to Billing, then Add-ons on the Organization page.

No other add-on is needed. The Aircraft and Fleet tabs work from the aircraft registered in your organization, so they have nothing to show until you have registered some; the Assess a log tab works with none: drop in any log and get a result.

The one rule worth knowing first#

A requirement that could not be decided is never reported as a pass.

Some requirements need a person to answer them; some need live state from ground infrastructure that no flight log carries. Those are listed as not assessed, counted separately, and stated in every report and claim. A tool that quietly counted them as passing would produce a much better-looking number and a worthless one. Every screen therefore shows two figures together: how much was decided, and how much was not.

Assurance levels#

Every assessment runs at one of three levels, which select different sets of requirements:

Level	For
L1	Baseline. Any operator flying on behalf of an organization.
L2	Standard. Public safety, or recurring operations over people or property.
L3	High consequence. DFR, tactical, or contested RF environments.

L2 is the default. Results at one level are never compared against another: they answer different questions.

Assessing a single log#

The page opens with a short statement of what UASVS is and is not, then tabs for the single log, the aircraft, the fleet and the conformance claim; the tab you are on is kept in the address. The assurance level is a set of radio buttons.

Open https://app.rotorlab.app/security.
Choose an assurance level.
Drop a .bin, .tlog or .ulg file onto the upload area, or press Choose a file to browse. The area names the file once it is chosen.

The log waits in line to be read, and the page shows your place until the report is ready. You can leave the page and come back: the Recent analyses list opens the report again. The file is held only until it is read, then deleted, and the report is kept for 7 days. The report shows:

a plain-English verdict: how many red and amber failures are open, and how many requirements could not be decided, with tiles that add up (a seventh tile appears only when something is flagged as incorrect);
What to fix, worst first, each with the setting to change;
every requirement, grouped by category, filterable and searchable.

After a read, the result comes first and the upload folds to Assess another log at the level you chose; Recent analyses is out of sight until you ask for it. Severity reads in words, a requirement that could not be assessed reads Not assessed with the reason, and one legend above the list and above the matrix explains the marks. A row's evidence opens as Evidence for the requirement. Only an organization admin or a member with security management can record a decision on a requirement. Without the Security Analyzer add-on the page says which add-on it needs.

Your organization's attested answers and recorded acceptances apply here too, so the same log reads the same way whichever screen you drop it on.

Assessing the logs you already have#

You do not need to upload anything twice. When flight logs are stored, the page opens on the Fleet tab, and an aircraft's summary offers a button such as Assess the 4 stored logs. The Fleet tab shows what is already stored: how many flight logs are held, how many have been assessed, and how many are waiting, per aircraft.

The picture shows the Fleet tab at level L2: the four figures, the Assess stored logs button and each aircraft's stored, assessed and waiting logs.

Press Assess stored logs to run them. The run waits in line like any other log reading, and the page shows its place until it is done. A log already assessed at that level, against that version of the standard, is skipped: the verdict cannot change, and only the date would move. Tick re-run ones already done to force it. Assessment is something you run, not something that happens on its own. Nothing is assessed until you ask for it.

One aircraft#

The Aircraft tab covers a single airframe:

Findings: the same results view as a single log, for that aircraft's latest assessment.
Previous runs: the last several runs, oldest first, and what changed between them: which requirement started failing, which was fixed, and which simply stopped being answered. Those are kept apart, because only the first two mean somebody changed the aircraft.
Stored logs: every log held for that airframe, and whether each has been assessed.
Answers: the attested answers that apply to this aircraft only (see below).

The aircraft's own page also carries a Security posture card summarising its latest assessment, with a link straight through.

Across the fleet#

The Fleet tab answers what to do next:

What to fix across the fleet: open failures gathered by requirement, worst first, naming the aircraft each affects. One requirement failing on four airframes is one job, not four findings scattered through a grid.
Configuration drift: requirements your aircraft answer differently. Only requirements decided on every airframe are compared: one that could not be assessed somewhere is a gap in the evidence, not a difference in configuration.
Requirement by aircraft: the full grid, with drift marked.

Questions only a person can answer#

Some requirements only apply under conditions no log can establish, such as whether a pilot radio is fitted or whether the board carries a hardware safety switch. The standard is explicit that a tool must never infer these from the data it is assessing, so the Operating profile tab asks them in the standard's own words.

Each question shows the requirements your answer decides. Your answer is an attestation: it is recorded against your name and the date, and it travels with your conformance claim.

Answer once for your organization, and override it on the airframes that differ under Aircraft, then Answers. An aircraft's answer wins over the organization's, question by question, so recording one exception does not cost you every other answer. Where an aircraft overrides an answer, the organization page says so.

Leave a question unanswered and the requirement is still assessed, with the open question raised alongside the verdict.

What you can do with a failure#

A failing requirement offers up to three actions, and they mean different things:

Accept this risk: the finding is right and you are carrying it anyway. Needs a reason and a name. It moves the requirement from failing to accepted, and accepted is never shown as passed: it stays in the report and in the conformance claim.

Does not apply here: the aircraft genuinely has no such thing. Offered only where the standard gates that requirement on a question a person can answer. This records the attestation, and on the next run the standard itself reports the requirement as not applicable. This is the correct route when, for example, an aircraft is flown with no pilot radio at all.

Flag as incorrect: the finding is wrong; the rule misread this airframe. Needs a reason and a name. It is taken out of the action list and the open counts, and it is still listed, with your reason, in the report and the conformance claim. Flagging changes no verdict: the standard still reports what it found.

Acceptances and flags are scoped to where you made them. One made on the Aircraft tab applies to that aircraft only, so carrying a risk on one airframe does not silently suppress the same finding across the fleet.

Reports#

Two PDFs, both carrying a verification code you can check at rotorlab.app/verify:

Security Assessment: one aircraft or one uploaded log. What was assessed and the log's SHA-256, a severity summary, what to fix with the rationale and the evidence behind each finding, then accepted, flagged, passing, and a full list of everything not assessed.

Fleet Security Posture: what to fix across every aircraft, gathered by requirement, then configuration drift.

The conformance claim#

The Conformance claim tab shows how many aircraft are assessed at the level, such as 0 of 6 aircraft assessed at L2; Issue the claim is the tab's main button only once at least one is. It issues a dated document stating what you attest, backed by machine results anyone can reproduce. It carries every aircraft assessed, the acceptance list, anything flagged as incorrect, and a plain statement of how much of the standard was never assessed, which is the part that makes it worth anything.

The claim prints on a page of its own: press Print or save as PDF and choose your browser's Save as PDF to keep a dated copy. The claim opens with your organization's name, the level and the day it was issued; it names each aircraft assessed and states the open questions in the standard's own words. On paper it ends with a line for the person who signs for the operator, "Signed for the operator", with a date. The page shows the claim's code and the address where anyone can verify it.

RotorLab does not certify anybody. Conformance under UASVS is self-attested. The claim reports the evidence behind what you are asserting; it is not a certificate and does not confer one.

Where the results come from#

Each report records the version of the standard it was assessed against, the SHA-256 of the log, and the as-of dates of the advisory and release tables used. A verdict reached against one version of the standard is not a verdict against another, so the Fleet tab counts "assessed at the version in force" separately from "assessed at some point".

Stored assessments are kept per aircraft and per level, with the most recent several retained so each run can report what changed since the last one.

Log Analyzer: free flight-log reading
Crash Analyzer: post-incident forensics
Supported log formats
uasvs.org: the standard itself