Name: ops0
Author: ops0

Question 1

What is the ops0 Security Hub?

Accepted Answer

It is one lasting issue list for every finding from every scan on AWS, Azure, Google Cloud and Oracle Cloud. Cloud posture checks, ops0 configuration checks, the internet exposure scan, the external surface and least privilege all land in the same place. A rescan updates the same issue instead of adding new rows, so history, owners and due dates stay attached to the problem.

Question 2

How does ops0 decide which issue to fix first?

Accepted Answer

Every issue gets a priority from 0 to 100, grouped into bands P1 (70 and up), P2 (50 to 69), P3 (30 to 49) and P4. The score starts from severity and adds points for a known-exploited vulnerability, the likelihood the flaw will be exploited, internet exposure, proven exposure, honeypot activity in the account, and several checks agreeing. Every point is listed with its reason, so nobody has to trust a black box.

Question 3

How do owners and SLAs work?

Accepted Answer

Each issue gets an owner automatically: one you set, the asset owner, the owner of the IaC project that manages the resource, or a cloud tag matched to a team member by email. The due date follows severity: critical 7 days, high 30, medium 90, low 180, and any known-exploited vulnerability gets 7 days. Overdue, due soon and within SLA are shown on every list and on the overview.

Question 4

What is an attack path and why does it matter?

Accepted Answer

An attack path is the chain an attacker would follow: an internet-facing workload, the role it can assume, and the data that role can reach. ops0 draws these across clouds from your real exposure and permissions, ranks them, and numbers each step. A pile of medium findings that line up into one path is more dangerous than a single high one, and the graph shows you which is which.

Question 5

How does ops0 build least-privilege policies?

Accepted Answer

It reads each cloud's own audit logs for 7, 30 or 90 days to see which permissions every user, role, group and service account actually used. The tightened policy keeps what was used, narrows wildcards to the actions seen, and removes what was never touched, with a reason on every line. It is delivered as code for a person to review and approve, and it runs on AWS, Azure, Google Cloud and Oracle Cloud.

Question 6

What are honeypots in the cloud?

Accepted Answer

Honeypots are believable decoys, such as an inactive access key, a storage bucket, a database endpoint, an SSH server or a fake admin panel. No real user has a reason to touch them, so any touch is a near-certain signal. A trip opens an incident with the attacker's location, network and the commands or passwords they tried, and ops0 can draft a policy that blocks the probed pattern.

Question 7

Can I accept a risk instead of fixing it?

Accepted Answer

Yes. Accept risk on any issue with a written reason and an expiry of 30, 90, 180 or 365 days. The acceptance is recorded in the issue history, and when it expires the issue reopens automatically if the problem is still there. That gives you a risk register that stays honest without a spreadsheet.

Question 8

How do security fixes get made?

Accepted Answer

Open Fix with Kiwi, ops0's assistant, from an issue or from the Security panel inside an IaC project. Kiwi drafts the change at the exact Terraform address, file and line. The change waits as a pending file for a person to approve and deploy through the normal plan and approval flow, and a later recheck confirms the issue is gone.

One list of every risk. Fixed as reviewed code.

A finding becomes one issue.

An attack path shows why it is P1.

The fix opens as code.

The recheck closes it.

Rank it, tighten it, trap it.

A score that shows its work.

Permissions cut to what was used.

Decoys that catch attackers early.

The rest of the security loop.

Common questions

See every risk once.
Fix the ones that matter.