Skip to main content
Version: 1.0.0

Cloud Resources

Most estates now run across on-premises infrastructure and one or more public clouds. Cloud Resources gives you a single place to record cloud-hosted assets β€” virtual machines, containers, managed databases, object storage, and the networks around them β€” and monitor their security posture next to the rest of your inventory. Cloud assets are not a separate silo: they flow into the same discovery, scanning, and Vulnerability Management workflows you use everywhere else in Cert-IX.

Coverage is expanding

Cert-IX covers cloud assets today through scanner agents, the Scan API, and manual entry. Native, API-based provider account connectors β€” read-only discovery that talks directly to AWS, Azure, GCP, and other provider APIs β€” are rolling out progressively and may not be available on every plan. Where a capability is in preview, this page calls it out.

How cloud assets enter your inventory​

There is no single "cloud connector" that does everything. Instead, you assemble cloud coverage from the same building blocks Cert-IX uses across your whole estate, choosing whichever fits each environment.

MethodBest forWhere it's documented
Scanner agentsVMs, containers, and networks you control inside a cloud VPC/VNetScanner Agents
Scan APIPublic-facing cloud endpoints (URLs, IPs, web apps, APIs)Scan API
Manual entryAssets you track by hand or import from another systemAsset Management Overview
Native provider connectors (preview)Account-level resource enumeration via provider APIsThis page

Scanner agents inside your cloud network​

The Cert-IX agents treat a cloud subnet exactly like any other internal network. Deployed on a jump host or a dedicated instance inside your VPC or VNet, they discover and continuously assess the workloads you run there:

  • Bitcollector reports asset telemetry β€” hosts, open ports, installed software, and system metrics.
  • Bitscanner performs vulnerability scanning and CVE detection against those hosts.
  • Bitmapper maps the network topology so you can see how cloud resources relate to one another.

Agents are downloaded from downloads.cert-ix.com and registered with your Tenant ID (found under Settings β†’ Organization). See Scanner Agents for deployment and configuration.

Scan API for public cloud endpoints​

Anything reachable at a public URL or IP β€” a load balancer, an API gateway, an internet-facing web application β€” can be assessed directly through the Scan API without deploying anything. Its engines (including Nmap, OWASP ZAP, Trivy, Nuclei, and Nikto) check externally reachable cloud services for open ports, web application vulnerabilities, and observable misconfigurations. Scans run asynchronously (queued β†’ running β†’ completed), and results feed the same findings views as agent-based scans.

Manual entry​

For assets that sit outside automated discovery, you can record cloud resources by hand so the inventory stays complete. Manually added resources appear alongside discovered ones and can be filtered, searched, and mapped to compliance controls.

Native provider connectors (preview)​

Where available for your plan, a read-only connection to a cloud account lets Cert-IX enumerate account-level resources and their configuration through the provider's own APIs. Follow the principle of least privilege: grant a scoped, read-only role or service credential β€” inventory and read access is all Cert-IX requires. Account-level discovery is being rolled out, so confirm availability before relying on it in place of agent- or scan-based coverage.

Working with cloud resources​

Resource inventory​

Discovered and manually added cloud assets share one list. You can filter by provider, resource type, and region, and search by name or identifier to narrow large estates quickly. Each resource carries the attributes returned by whichever method discovered it.

Resource details​

Selecting a resource shows its configuration data, the other resources it relates to, and the security findings raised against it. Where a resource maps to a compliance control, its status surfaces here too.

Cloud security posture​

Cloud findings are produced by the same scanning surfaces as the rest of the platform and ranked by the same severity model, so cloud risk is comparable with everything else you manage.

Exposure and vulnerability findings​

Agents and the Scan API surface issues you can observe from the network: open or unexpected ports, reachable services, web-application vulnerabilities, weak transport security, and hosts running software with known CVEs. Findings are ranked Critical / High / Medium / Low in Vulnerability Management, each with remediation guidance describing the issue and the recommended fix.

note

Deeper cloud-configuration checks β€” such as storage-bucket exposure, over-permissive IAM policies, or unencrypted volumes read straight from a provider's configuration APIs β€” depend on the native provider connectors described above and expand as that preview capability rolls out. Externally observable exposure, such as open ports and reachable or misconfigured services, is covered today through scanning.

Remediation​

Each finding includes a description, a severity, and step-by-step remediation guidance. You apply the recommended changes in your own cloud environment, and Cert-IX re-scans on the next cycle to confirm the issue is resolved. Cert-IX guides remediation rather than making changes in your cloud account on your behalf.

Compliance tracking (Beta)​

Cert-IX's Compliance module β€” currently in Beta β€” lets you track cloud and on-premises assets against frameworks including NIST CSF, ISO 27001, SOC 2, CIS Controls, and NIS2, as well as custom frameworks you define. Where the Bitenforcer agent is deployed, it additionally runs compliance-hardening checks (CIS, STIG, PCI-DSS) directly on the host. Because Compliance is still evolving, treat its coverage as a working view of posture rather than a certification of record.

Security and data handling​

Cloud connections use scoped, read-only credentials, and platform access is protected by Cert-IX's standard controls: post-quantum ML-KEM (FIPS 203) protecting authentication, multi-factor authentication via TOTP and WebAuthn/FIDO2, short-lived ES256 session tokens, and role-based access control. Infrastructure is EU-hosted, with some US sub-processors engaged under Standard Contractual Clauses. Cert-IX is GDPR-aligned; see the privacy notice for details.

Best practices​

  1. Deploy agents in each cloud environment so the workloads you control are inventoried and scanned continuously.
  2. Scan public endpoints regularly with the Scan API to catch externally reachable exposure early.
  3. Prioritize by severity in Vulnerability Management, addressing Critical and High findings first.
  4. Track framework posture in Compliance (Beta) to see how cloud assets measure against your target controls.

Learn more​

Was this page helpful?