Before
Network responders had to inspect pending requests, read the current list state, and manually merge additions and removals into separate blocklist files. They also had to remove expired or duplicate entries, enforce list limits, verify the repository publication, and clear the processed queue without losing requests when a publication failed.
How it works
- Collect pending indicator requests and validate the current repository head, commit, and list metadata.
- Merge reviewed decisions deterministically, applying precedence, withdrawals, expiration rules, deduplication, and the 5,000-entry-per-list ceiling.
- Publish the revised lists as one verified revision, then clear processed requests only when the publication is complete.
Workflow details
- Trigger and intake: A scheduled or on-demand run lists pending indicator requests and reads each request, including its action, indicator type, value, expiration period, ticket, source, reason, and request time. If no requests are pending, the flow returns a no-publication result.
- Repository validation: The workflow reads the current branch state, its commit information, and the existing list metadata. It permits an absent metadata file during the first pass but stops safely when required repository data is unreadable, preventing an accidental empty rewrite.
- Deterministic merge: The flow combines pending decisions with the current lists, gives precedence to the most recent request, applies removals and TTL-based expiration, removes duplicates, and enforces a maximum of 5,000 entries per list while retaining the first analyst decisions when entries must be limited.
- Publication and verification: It prepares the metadata and separate IP, domain, and URL blocklist files, publishes them in one repository revision, and verifies that the new revision and branch state match before treating the update as complete.
- Safe cleanup and reporting: Processed requests are cleared only after successful publication. Repository-read failures or branch movement leave requests intact for the next run, while the final result reports whether publication completed and how many entries were added, removed, expired, and retained.
What changed
The repository becomes the controlled publication point for refreshed firewall lists: requests are merged and validated automatically, the three list files are published together, and cleanup occurs only after the new revision is confirmed. If repository data is unreadable or the branch changes during publication, the requests remain available for a later retry.
Work removed
Listing and reading requests one by one, merging additions and removals, deduplicating indicators, removing expired entries, enforcing per-list limits, editing list and metadata files, verifying publication state, and clearing processed requests by hand.
Expected outcome
Each successful run applies the same precedence and expiration rules and is designed to complete the publication in about eight repository calls, regardless of list size; this is an estimate based on the workflow design, not a measured customer result.
