Setting Opinions

An opinion is your team's own conclusion, recorded in Stairwell so that it outlives the investigation that produced it. You set one when you have decided something the platform could not: that a file it flagged is your own build tooling, that a file nothing flagged is the intrusion, or that a domain your files keep referencing is your own vendor. Opinions apply to files, hostnames, and IP addresses, and inside your environment they take precedence over the automated verdict. If you want the concept first, read What is an opinion? and come back.

What are the values and what does each one mean?

Six, and the vocabulary is fixed.

Value	Use it when
No opinion	The starting state. Leave the call to automated analysis
Trusted	You have reviewed it and it is legitimate and authorized here
Benign	It is not malicious
Vulnerable	It carries a known security weakness, such as an exploitable flaw or an outdated bundled library. This records a judgment about exposure, not about intent
Grayware	Not malicious, but unwanted or risky in your context: adware, a dual-use administration tool, software your policy prohibits
Malicious	You have established that it is a threat

Vulnerable sits on a different axis from the others. A library with a published flaw is not malware, and treating it as though it were would be wrong, so this value exists for the patching and hygiene workflows where the question is risk rather than malice.

That difference has a practical consequence worth knowing: Vulnerable does not change the verdict. The other values override what automated analysis concluded, and Vulnerable does not, because it is not a claim about whether the file is malicious. Automated analysis keeps running and the verdict stays whatever the evidence says. So you can mark a vulnerable library without losing the platform's read on it, which is exactly what you want when the file is both legitimate and a liability.

What does setting an opinion actually change?

Setting one is closer to configuration than to annotation. Within the environment you set it in:

Marking something Malicious makes that the verdict readers of your environment see, whatever the engines concluded.
Marking something Trusted or Benign makes the verdict safe and takes the file out of threat report match counts, which is how you stop a legitimate tool from inflating every report's numbers.
Marking something Grayware records that it is unwanted without asserting that it is malware.

Notification suppression reaches further than the environment, so know its blast radius before you use it for that. A Trusted or Benign opinion stops notifications for any trigger your organization owns, as long as that safe opinion exists in any environment the organization can read. It is not scoped to the one environment you set it in. That is usually what you want when you have decided a file is your own tooling, and it is worth knowing when you have not: setting Trusted in a test environment quiets the file organization-wide. See Trigger Silences when you want to quiet specific noise without making a claim about the file itself.

The decision also travels. The opinion shows up next to that file everywhere it appears, including inside somebody else's variant list, so a colleague reaching the file from a different direction sees your conclusion rather than repeating your work.

And it can wake people up. A trigger can fire when an opinion changes in an environment, which is how a team of more than one person stays in sync about what has been decided.

Whose opinion wins?

Yours, inside your environment.

Stairwell's own research can set an opinion that applies as the default everywhere. Your environment's opinion overrides that default, and only within your environment. If Stairwell's researchers call a dual-use tool Grayware and your policy prohibits it on your fleet, you mark it Malicious, and that is what your team sees. Nobody else's view changes, and the global assessment is not weakened by your local decision.

This is also why the environment an opinion lands in matters. See Environments.

How do I set one on a file?

Open the file's object panel. See The Object Panel.
Use the opinion control at the top of the panel. The Update opinion form opens.
Check that the environment named in the form is the one you mean. It defaults to your default writable environment, and you can change it there.
Select a value.
Write a comment. It is optional and you should write it anyway, because the value of a conclusion is mostly in the reasoning, and six months from now the reasoning is the part nobody can reconstruct.
Select Update. Ctrl+Enter, or Cmd+Enter on a Mac, submits the form without reaching for the mouse.

The change takes effect immediately. You need write access to the environment; a read-only account can see opinions but not set them.

You can also set one from the Variants detail pane, without leaving the investigation. Judging a cluster is often faster than judging one file at a time, since the members that resemble each other usually deserve the same call.

How do I set one on a hostname or an IP address?

The same way, from the hostname or IP address panel, which carries the same opinion control at the top and the same history underneath.

This is what makes a conclusion about infrastructure as durable as a conclusion about a binary. When you establish that a domain is your own software vendor's update service, record it, and the next analyst who finds that domain inside a file starts from your answer rather than from scratch. Marking a domain Malicious works the same way in reverse. See Network Intelligence.

Can I do this through the API?

Yes, for all three entity types. Each takes a list request and a create request.

GET  /v1/objects/{SHA256}/opinions
POST /v1/objects/{SHA256}/opinions

GET  /v1/hostnames/{hostname}/opinions
POST /v1/hostnames/{hostname}/opinions

GET  /v1/ipAddresses/{ip}/opinions
POST /v1/ipAddresses/{ip}/opinions

One vocabulary trap when you automate: in the API an opinion is carried in a field named verdict, while the automated conclusion is also called a verdict. Read the resource you are writing to, not the field name alone.

Where do I see opinions afterwards?

On the entity itself, as the verdict readers of your environment see.
The History tab of the object, hostname, or IP address panel, which records each change: who made it, when, in which environment, and what the previous value was. That is the audit trail, and it is what makes an opinion defensible rather than merely convenient.
The Opinion column in search results, so you can filter a hunt to what has and has not been judged. object.opinion is a searchable field. See CEL Query Language.
Variant lists, where a judged member of a cluster often settles the unjudged ones.

What should I read next?

What is an opinion?, for why the feature exists and what it replaces.
Verdicts, the automated conclusion an opinion takes precedence over.
Run-to-Ground, where marking common software Trusted visibly cleans up the next result.