July 27, 2026

Build a recurring security.txt coverage control for domain portfolios

Turn public security.txt checks into a repeatable portfolio control that identifies missing or expired disclosure contacts and routes only actionable exceptions to vendor-risk or managed-security teams.

Short answer: Run Security.txt Checker against a bounded portfolio of public domains on a weekly or monthly cadence, retain the structured status for each domain, and route only new missing or expired results for follow-up. This creates a repeatable coverage control without treating security.txt presence as proof of a complete vulnerability-management program.

Commercial use: A managed portfolio-control use case with scheduled exception routing will encourage service providers and vendor-risk teams to rerun the Actor for every reporting cycle, increasing repeat paid domain checks rather than one-time lookups.

Verified proof run

Public input shape

{
  "includeRootFallback": "<boolean>",
  "maxResults": "<number>",
  "proxyConfiguration": {
    "useApifyProxy": "<boolean>"
  },
  "startUrls": [
    "<string>"
  ]
}

Output shape

[
  {
    "domain": "<string>",
    "checkedUrl": "<string>",
    "finalUrl": "<string>",
    "status": "<string>",
    "hasSecurityTxt": "<string>"
  }
]

Why security contact coverage changes over time

A public security.txt file is operational data rather than a permanent certification. RFC 9116 requires a Contact field and an Expires field, so a file that was usable during vendor onboarding can later disappear or become stale. Recurring checks are therefore more useful than a one-time spreadsheet for teams responsible for an evolving domain portfolio.

Source

Define the portfolio control

Keep an approved list of public customer, supplier, or product domains and assign each domain an internal owner outside the Actor. Submit only the domain list to the Actor, cap the result count, and preserve a stable domain identifier downstream so each reporting cycle can distinguish a new exception from an unchanged condition.

Use the standard well-known path as the primary control. Enable the optional root fallback only when the reporting policy explicitly needs visibility into the legacy location, because the two locations should not be presented as equivalent conformance evidence.

Source Source

Interpret structured findings consistently

The Actor returns one structured item per checked domain, including the checked URL, found or missing status, parsed expiry, and available contact or policy fields. Treat missing and expired results as review queues, not automatic compliance failures, and avoid copying public contact values into broad notifications when a domain-level status is enough.

A found file proves only that the resource was retrieved and parsed during that run. It does not prove that the listed channel is monitored, that reports receive a response, or that the organization operates a complete disclosure program.

Source Source

Route exceptions through n8n

An n8n workflow fits this cross-system operations case: a schedule trigger starts the cycle, the workflow prepares a bounded domain list, starts one Actor run, polls that same run to a terminal state, retrieves the dataset, and compares domain statuses with the prior successful cycle.

Route only newly missing files, newly expired files, or meaningful expiry changes to the case-management destination. Keep raw public contact fields in the restricted result store unless the destination needs them, and include an explicit failure branch so an Actor or dataset error cannot be mistaken for a clean portfolio.

Source Source

Choose one scheduling owner

Apify schedules can start Actors or tasks from cron expressions, while n8n can also own the interval. Use exactly one scheduler for the same portfolio control: if n8n performs comparison and delivery, let n8n trigger the run and leave the equivalent Apify schedule disabled to prevent duplicate paid checks.

Record the intended timezone and reporting cadence with the workflow. A weekly cycle can suit operational monitoring, while a monthly cycle may align with supplier reporting; the appropriate interval is a policy decision rather than a claim made by the Actor.

Source Source

Measure whether the use case creates recurring value

Begin with a small public-domain portfolio and verify that the exception routing reduces repeated manual checks. At J+7, J+30, and J+90, compare successful public Actor runs and external-user signals with the saved baseline. These are usage proxies unless attributable paying-customer and revenue data become available; they must not be reported as MRR by themselves.

Source

Reusable automation

Open the tested n8n example.

Run one bounded public-domain check, inspect the structured status, and then connect an approved portfolio to the n8n exception workflow for the next reporting cycle.

Run the Actor on Apify.