Verify software before execute and before upgrade
Automation executes and upgrades without a human in the loop. The action boundaries that matter are before execute and before upgrade. Attestd is the check at those moments.
Provisioning scripts already know the product name and version. What they lack is a machine-readable answer before the change runs or the version pin moves.
- →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 change already executed. 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 safe to execute or upgrade to.
- →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 execute
Call /v1/check after resolving the version you will run, and before the provisioner applies the change. Treat critical risk_state and supply_chain.compromised as a hard stop.
- 02
Check before upgrade
When automation bumps a version pin or rolls a fleet, verify the target version before the upgrade runs. Use fixed_version only after Attestd confirms the candidate is acceptable.
- 03
Fail closed on active remote exploits before expose
If the next step opens ingress, also treat actively_exploited and remote_exploitable together as a hard stop for internet-facing roles.
Automation executes and upgrades only after software is verified.
Infrastructure pipelines can run autonomously at scale. When Attestd returns a blocking signal on a version about to execute or upgrade, the 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.