Most web security problems are not exotic. They are a security header that was dropped in a config refactor, a TLS setting that regressed, a DMARC record left at p=none, or a DNSSEC chain that silently broke. None of them show up in a unit test, and none of them wait for your annual review. By the time a quarterly scan notices, the regression has been live for weeks.
AssurePort Security Check closes that gap by moving the check to where the change happens: your pipeline. It is a free GitHub Action that runs a passive, read-only assessment of a domain you own on every push or pull request, and — when you want it — posts the result straight into the PR as a comment, so a reviewer sees the posture before the merge, not after the incident.
What the Action Checks
The Action wraps the same free intelligence tools AssurePort already publishes on its free toolkit page and runs them together against the domain you point it at. Every check reads publicly observable configuration — nothing more. In a single run it reports on:
| Check | What it looks at |
|---|---|
| Security headers | HSTS, Content-Security-Policy, X-Frame-Options, referrer and related response headers, graded against a baseline. |
| TLS configuration | Protocol versions, certificate validity and expiry, and basic cryptographic hygiene observable from the handshake. |
| Login surface | Passively detected SSO providers and multi-factor signals on a public login page — read-only, no sign-in attempts. |
| Email authentication | SPF, DKIM and DMARC records, and whether they are aligned enough to stop trivial spoofing of your domain. |
| DNSSEC | Whether the cryptographic DNSSEC validation chain is present and intact. |
| HSTS preload | Whether the domain is on the browser HSTS preload list, forcing HTTPS from the first visit. |
Each item resolves to a clear pass, warning or fail with a short explanation, so the output is readable by a developer who is not a security specialist. The point is not to produce a hundred-line report; it is to catch the handful of regressions that actually matter, on the commit that introduced them.
Adding It to a Workflow
The Action is published on the GitHub Marketplace and takes a single required input — the domain to check. A minimal workflow is one step:
name: Security check
on: [push, pull_request]
jobs:
assureport:
runs-on: ubuntu-latest
steps:
- uses: assureport/assureport-security-check@v1
with:
domain: example.comThat is the whole setup. It runs on GitHub-hosted runners, needs no API key for the baseline checks, and writes a summary to the workflow run. If you want the report to appear as a comment on the pull request, give the job pull-requests: write permission and the Action will post there automatically. Pin to the major tag — @v1 — to pick up compatible updates, or pin to a specific release if your policy requires it.
Where it fits: treat the Action as a fast, always-on smoke test for your public posture — the security equivalent of a linter. It runs in seconds, costs nothing, and never blocks a deploy unless you choose to fail the job on a specific finding. It is a tripwire, not a gate.
The Pull-Request Comment
The most useful mode is the PR comment. When the Action runs on a pull request and has write permission, it posts a compact summary table of the checks and their status directly in the conversation, and updates that same comment on each new push rather than stacking duplicates. A reviewer scanning the PR sees at a glance whether the change touched anything that moved the posture — a dropped header, a weaker TLS setting — without leaving GitHub.
This is where catching a regression in CI pays off. A misconfiguration that would otherwise be invisible until the next external scan becomes a line in a review the day it is written, when the context is fresh and the fix is a one-line revert rather than an incident ticket.
Authorization and Privacy
The Action is passive and read-only by design. It performs the same public DNS, TLS and HTTP-header lookups that anyone can run against an internet-facing endpoint. It never sends an exploit, never submits a login form, never tries to break or change anything, and does not read your repository's source code or secrets. The only input it needs is the domain name.
Point it at a domain you own or are authorised to assess. The low footprint of passive checks does not remove that responsibility — the authorization boundary for this Action is the same one you apply to any security tooling in your pipeline. On the data side, AssurePort runs with EU data residency across its infrastructure, and customers who go on to run a full test are covered by a Data Processing Agreement.
A Surface Check, Not a Pentest
It is worth being precise about what this is and is not. The Action answers one question: is my public surface configured well? It does not answer the harder one: is my application exploitable? Those are different jobs. A surface check reads configuration; a penetration test actively chains weaknesses into a proven attack path and produces evidence.
A domain can pass every check the Action runs — perfect headers, strong TLS, aligned email records — and still carry an exploitable business-logic flaw, a broken access control, or an injection bug that only a real test will surface. We build the Action so it never overclaims: a green run means your observable hygiene is sound, not that you are secure. That honest boundary is the whole reason the Action carries a pointer to the deeper test, rather than pretending to replace it.
From CI Check to a Full Test
When the Action flags something that deserves a closer look — or when you simply want to know what is exploitable rather than merely misconfigured — it links through to AssurePort's full AI-driven penetration test. That is the paid platform: an authorized pipeline that runs real exploitation safely, backs every finding with a reproducible proof of concept, and ships remediation guidance in your stack's language, starting at $69 per web scan. The free Action is the continuous tripwire; the pentest is the deep, evidence-backed assessment you run when the tripwire fires or on your compliance cadence.
The two are designed to work together: run the Action on every pull request to hold your public hygiene in place between tests, and run the full pentest when you need proof — for a release, an audit, or an incident. For the methodology behind the deeper test, see our pillar guide to penetration testing, and our walkthrough of how attack surface discovery finds the assets a config check alone would miss.
Conclusion
Security configuration regresses the same way code does — quietly, on an ordinary merge — and the cheapest place to catch it is the pull request that caused it. AssurePort Security Check puts a free, passive, read-only posture check right there in CI, with the result in the PR comment where a reviewer will actually see it.
- Free and passive. Public, read-only lookups on a domain you own — no API key for the baseline, no exploitation, no access to your code.
- In the review, not the backlog. A PR comment on every change beats a quarterly scan that notices weeks late.
- Honest about scope. It is a surface check, not a pentest — and it says so, pointing to the full test when you need proof.
Add the Action to one workflow, point it at your domain, and let your pipeline hold the line between tests.
Frequently Asked Questions
What is the AssurePort Security Check GitHub Action?
It is a free GitHub Action that runs a passive, read-only security check against a domain you own on every push or pull request — security headers, TLS, the login surface (SSO and MFA signals), email authentication (SPF, DKIM, DMARC), DNSSEC and HSTS — and summarises the result in the CI run and, optionally, as a PR comment. It wraps the same free intel tools AssurePort publishes on its website.
Is the GitHub Action a penetration test?
No. It is a passive surface check — it reads publicly observable configuration and never sends an exploit or submits a login. It answers "is this configured well?", not "is this exploitable?". For proof-of-concept evidence you run AssurePort's full AI-driven penetration test, which the Action links to.
What domains am I allowed to check with it?
Only a domain you own or are authorised to assess. The checks are passive and read-only — the same lookups anyone can run against a public endpoint — but you should still point the Action at your own domains and treat the authorization boundary as you would for any security tooling.
How do I add it to a workflow?
Add a step that uses assureport/assureport-security-check@v1 and passes the domain input, for example domain: example.com. It runs on GitHub-hosted runners, needs no API key for the baseline checks, and can post the report as a PR comment when granted pull-requests: write permission.
Does it send any of my data to AssurePort?
The Action performs public, passive lookups against the domain you specify — the kind of DNS, TLS and HTTP-header queries observable to anyone. It does not read your source code or secrets. AssurePort operates with EU data residency, and the full platform is governed by a Data Processing Agreement for customers who run a complete pentest.