Assets
An asset is anything the CyberOptix CTEM Platform can find a problem on. Findings attach to assets, scope is expressed in terms of assets, and reporting counts them - so what does and does not become one shapes everything else.
The definition is broader than "server". A storage bucket, an IAM user, a Kubernetes cluster, a source repository and a web application are all assets, because all of them can be misconfigured or vulnerable.
Where assets come from
Assets are discovered, not entered. Four routes:
| Source | Finds |
|---|---|
| Scanners | Hosts and services on the networks in your zones |
| External discovery | Internet-facing hosts, web applications, and certificates for your verified domains |
| Cloud integrations | Compute, storage, databases, networking, identity and more, across connected accounts |
| Source control integrations | Repositories, and the applications built from them |
Cloud coverage is the largest of these by some distance - around 50 distinct resource types across AWS and Azure - which is why Cloud Exposure has more sections than anything else in the product.
You will not create assets by hand. What you control is scope: verify a domain and external discovery begins; add a subnet to a zone and scanners start finding what is in it; connect a cloud account and its resources appear.
The same machine, more than once
This surprises people, so it is worth stating plainly: one physical or virtual machine can legitimately appear as several assets.
An EC2 instance that is also internet-facing and also running a web application may be discovered three ways - as a cloud resource by the AWS integration, as a host by external discovery, and as a web application by scanning. Those are three different views, and they carry different findings.
That is deliberate rather than a deduplication failure. The AWS integration knows things external discovery cannot - the security group, the IAM role, whether the volume is encrypted - and external discovery knows things AWS cannot, like what the service actually answers with from the outside. Collapsing them would lose one or the other.
Where the platform can confidently tie views together, it does, and the asset detail view shows the relationships.
What attaches to an asset
| Attachment | Purpose |
|---|---|
| Findings | Problems on this asset |
| Business unit | Who owns it |
| Zone | Where it sits, for scanning |
| Tags | Anything else you sort by |
Business unit and tags are the two you should actually invest in. They are what turn a flat inventory into something answerable: "Critical findings on internet-facing assets owned by Payments" needs both.
See Organizations, business units, and zones.
Assets that disappear
Cloud resources are created and destroyed constantly, and so is their presence here.
An asset that stops being discovered is not deleted - its findings and history remain, because "this bucket was public for six weeks before it was deleted" is exactly the sort of thing an audit asks about later.
A host that vanishes from discovery is also worth a look before you assume it was decommissioned. Scanners only see what they can reach, so an asset disappearing can mean the machine is gone, or it can mean a firewall changed, a zone was edited, or the scanner covering it stopped reporting. Troubleshooting covers the last of those.
Next
- Findings, severity, and risk - what attaches to assets
- Organizations, business units, and zones - how assets are scoped
- Attack Surface - assets discovered from outside