Warn before exposing unsafe systems to the internet
Infrastructure automation is fast, consistent, and unforgiving. When it provisions a service with an active exploit and immediately exposes it, there is no human in the loop to catch it. attestd acts as that check.
Provisioning scripts already know the product name and version. What they lack is a machine-readable answer before the security group or load balancer opens the path.
- →Parsing NVD CPE ranges at provision time is slow and error-prone. Version boundaries are easy to get wrong under time pressure.
- →A daily CVE digest arrives after the service is already public. Automation and attackers both operate in minutes, not days.
- →"Is this CVSS high?" is the wrong question for a provisioner. The right question is whether the version is actively exploited and remotely reachable.
- →Container-to-host pivots start from exposed software. Once the network path exists, minutes matter.
Halt provisioning when remote exposure would put an actively exploited version on a public interface.
| Field | Meaning for this use case |
|---|---|
actively_exploited | Primary block when combined with remote_exploitable. Confirmed exploitation, not theoretical severity. |
remote_exploitable | True when the condition can be triggered over the network. Pair with actively_exploited before opening ingress. |
risk_state | Fail closed on critical for any internet-facing service, even without a confirmed active exploit flag. |
supply_chain.compromised | Block images or packages pulled into the provision path when compromise is confirmed. |
fixed_version | Upgrade target for the next Terraform/Ansible/Pulumi run. Log it when the provisioner aborts. |
curl "https://api.attestd.io/v1/check?product=openssh&version=9.6" \
-H "Authorization: Bearer $ATTESTD_API_KEY"import os
import attestd
client = attestd.Client(api_key=os.environ["ATTESTD_API_KEY"])
def safe_to_expose(product: str, version: str) -> bool:
risk = client.check(product, version)
if risk.supply_chain and risk.supply_chain.compromised:
print(f"[BLOCKED] {product}@{version}. Supply chain compromise")
return False
if risk.actively_exploited and risk.remote_exploitable:
print(f"[BLOCKED] {product}@{version}. Active remote exploit detected")
print(f" risk_state: {risk.risk_state}")
print(f" fixed_version: {risk.fixed_version}")
return False
if risk.risk_state == "critical":
print(f"[BLOCKED] {product}@{version}. risk_state=critical")
print(f" fixed_version: {risk.fixed_version}")
return False
return True
# Before provisioning a public-facing service
if not safe_to_expose("openssh", "9.6"):
raise SystemExit("Provisioning halted: unsafe software version")
# Proceed with infrastructure provisioning
provision_service()- 01
Check before opening ingress
Call /v1/check after resolving the version you will install, and before attaching a public security group, load balancer, or Ingress rule.
- 02
Fail closed on active remote exploits
Treat actively_exploited and remote_exploitable together as a hard stop. Also fail on critical risk_state for internet-facing roles.
- 03
Feed fixed_version into the next run
When the provisioner aborts, write fixed_version into the job log or ticket so the version pin updates without a separate research step.
Unsafe software versions never reach a public network interface.
Infrastructure pipelines can run autonomously at scale. When attestd returns an active exploit signal on a version about to be exposed, the provisioning step aborts cleanly with the upgrade path included.
ENCFORGE's container-to-host pivot shows what happens when unsafe software is exposed to the network: an agent found an open Docker socket and built a host breakout in five minutes and 24 seconds.
The openssh example above is the same shape of check: version boundaries matter before a service reaches a public interface. See Attestd vs NVD for why synthesized version risk beats parsing CVE records at provision time.
That is the machine-speed argument: provisioning automation and autonomous attackers operate in the same time domain. A daily digest does not.