ASL Scan — Source library
Public documentation snapshot: 2026-09-08
Prove the posture. Prove you were allowed to look.
Signed-scope security assessments your client authorizes, your analyst verifies, and no one can quietly edit after the fact.
Prove the posture. Prove you were allowed to look.
Built for: Managed service providers who assess client systems and need proof, not promises · Independent security consultants delivering posture reviews to small businesses · IT leads who have to show a board or an auditor where their systems stand · Firms that must document that an assessment was authorized, bounded, and unaltered
ASL Scan exists because of this.
An assessment is only worth as much as its authorization and its evidence. When you tell a client "I checked your systems and here's what I found," two questions follow that a spreadsheet can't answer: were you actually allowed to touch those machines, and is the document they're reading the same one your tool produced? "Trust me, I scanned it" does not survive a contract dispute, an insurance claim, or an auditor who wasn't in the room. Most assessment tools make this harder, not easier. They want an agent installed with broad rights, they reach for credentials, and some will happily run whatever a central server tells them to run on a client's machine. The results land in a document anyone can edit afterward, and a check the tool couldn't actually run quietly shows up as a green mark anyway - so a real gap looks identical to a clean pass. Often the person delivering the findings can't tell the difference either. For a small provider or a solo consultant, that is a real liability. You need to show a client where they stand without becoming the most dangerous thing on their network, and you need a record that holds up if anyone ever asks how you know what you claim to know.
ASL Scan exists because of this.
The authorization itself is cryptographic - the check refuses to run outside a signed list of exact hosts, so "were you allowed to scan this?" has a provable answer.
ASL Scan exists because of this.
An unmeasured control never counts as a pass; a scheduled run where every applicable rule is unknown fails as a dead instrument rather than reporting clean.
ASL Scan exists because of this.
Evidence is sealed at collection and re-verified before scoring, so a report can't be quietly edited after the fact.
ASL Scan exists because of this.
Read-only from the ground up - no agent with broad rights, no credentials touched, no server-supplied commands.
ASL Scan exists because of this.
The read-only assessment and the active-attack tier are separate products with separate authorizations; one can never silently borrow the other's permission.
ASL Scan exists because of this.
The platform holds itself to its own standard with a daily scheduled self-audit and an append-only history of every change.
How ASL Scan works, start to finish.
ASL Scan turns both halves of an assessment - the permission and the evidence - into something you can prove. Before anything runs, someone on your side issues a signed authorization that names the exact machines, the operating systems, who approved it, and an expiry date. The check refuses to look at any host that authorization doesn't name, and it stops the moment the authorization expires. There is no wildcard that quietly widens the scope. The check itself runs on the client's own machine and reads only settings - is the firewall on, is disk encryption active, is the remote-desktop login locked down, is antivirus current within the last seven days. It never touches passwords, never opens files or data, and never runs a command handed to it by a server. It measures sixteen hardening controls on Windows and seventeen on Linux, plus two that apply to both - thirty-five in all. Each one returns one of four honest answers: pass, fail, unknown, or not-applicable. An unknown is never upgraded to a pass, so a control you couldn't measure stays visible instead of hiding behind a green mark. When the check finishes it seals the results with a tamper-evident fingerprint and hands you a bundle. Your analyst signs in to a private workspace, and the workspace re-checks every fingerprint before it will score anything - so a bundle that was edited after collection is rejected, not quietly accepted. From there you get severity-weighted risk, a view of what changed on a host since the last visit, and export-ready reports you can hand to the client. Above the read-only check sits a heavier, separately authorized tier for teams that need to prove an application actually withstands specific attacks - not just that a setting is present. It issues real, bounded, tightly gated traffic against systems the owner has signed off as disposable, and it refuses to run without an explicit authorization flag and a working emergency stop. There is also a separate business-audit workspace that turns a full review into a repeatable engagement: sixteen evidence-backed sections, every finding carrying a business impact, a concrete fix, an effort estimate, an owner, and a test that proves it is closed. Everything is built to be defensible from the ground up. The authorization is cryptographic, the evidence is sealed, unknowns are loud, and the platform keeps an append-only record of its own history. It never claims a certification, never promises a system is free of every flaw, and always keeps a human review before a report reaches a client.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
Signed-scope authorization
Before a single check runs, someone on your side issues a signed authorization that names the exact hosts, the platforms, the person who approved it, and an expiry. The check refuses to measure any machine outside that list and stops when it expires. A wildcard can't quietly widen what you're allowed to touch.
Read-only by design
The check reads settings, not secrets. It never touches passwords, never opens files or customer data, and never runs a command a server handed it. That keeps your engagement defensible and keeps you from becoming the riskiest thing on the client's network.
Honest four-state results
Every control returns pass, fail, unknown, or not-applicable - and an unknown is never turned into a pass. A check the tool couldn't run stays visible as unknown instead of hiding behind a green mark. The scheduled self-assessment goes further: if every applicable rule comes back unknown, the run is failed as a broken instrument rather than reported as a clean bill of health.
Deep Windows coverage
On Windows the check measures sixteen hardening controls: the elevation prompt, all firewall profiles, antivirus real-time state and whether its intelligence is current within seven days, remote-desktop login hardening, legacy file-sharing exposure, activity logging, credential-store protection, anonymous account enumeration, update availability, pending reboot, secure boot, and disk encryption. The settings a small business most often gets wrong are exactly the ones it measures.
Deep Linux coverage
On Linux it measures seventeen controls of the same class: remote-login policy, the host firewall, audit logging, mandatory access control, address-space randomization, privileged core dumps, process-memory isolation, sensitive file permissions, routing and redirect settings, service health, time sync, and pending-reboot state. A missing platform tool produces an explicit unknown rather than stopping the scan.
Risky-listener detection
It flags exposure across sixteen sensitive service ports, so an unexpected database, remote-desktop, or file-sharing service listening where it shouldn't surfaces in the report instead of going unnoticed. A flag is a reason to look, not proof of a vulnerability, and the report says so plainly rather than crying wolf.
Tamper-evident evidence
Results are sealed with a fingerprint the moment they're collected, and the review workspace re-checks every fingerprint before it scores anything. A bundle that was edited after the fact is rejected. The report you deliver is provably the report the tool produced.
Drift and severity over time
The workspace compares a host against its own earlier results, so you can see what was introduced, what persists, and what was resolved since the last visit, and it weights findings by severity so the client's attention lands on what matters first. Exports are formatted to open cleanly in a spreadsheet without a formula surprise.
Signed custom rule packs
You can add your own industry or client-specific checks, but an unsigned or tampered rule pack is refused outright - nobody slips in an unvetted check. Every result keeps the exact rule and version that produced it, so a finding is always traceable back to the check that raised it.
Scheduled self-audit
On ASL's own systems the checks run on a daily schedule and escalate real findings, under a strict three-outcome convention that refuses to confuse "nothing wrong" with "the check couldn't run." Imported evidence that is stale or can't name the collector that produced it is a hard failure, never an unknown. It is the same honesty discipline the product sells, held against the people who built it.
Separate business-audit workspace
A distinct workspace turns a full review into a repeatable, priced engagement across sixteen evidence-backed sections. Every finding must carry a business impact, a concrete fix, a low and high effort estimate, an owner, and a test that proves it's closed - so the client gets a plan, not a list of scary words. A section with no evidence stays visibly incomplete rather than being counted as a pass.
Gated active-attack tier
For teams that need to prove an application actually withstands specific attacks, a heavier tier issues real, bounded, tightly gated traffic against owner-approved disposable systems, spanning thirty-three technique families today. It won't run without an explicit authorization flag and a working emergency stop file, and it refuses the riskiest, state-changing cases against anything marked production.
Offline Android evidence reviewer
A native Android app opens a sealed evidence bundle on the phone and verifies its fingerprints locally - a tampered, mismatched, or unsupported bundle is rejected without showing results, and imported evidence stays in memory and clears when the app closes. It works with no network access and holds no infrastructure credential. Its remote engagement-status and run-control screens are built but deliberately switched off until sign-in and the gateway are activated.
Nothing sensitive leaves the machine
The evidence deliberately keeps counts and yes/no facts, never the underlying content: no passwords, no tokens, no page bodies, no network addresses, no certificate identities. What you collect is a posture record, not a pile of client secrets waiting to leak.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Surfaces and status.
Status as of 2026-09-02. The analyst workspace is deployed and responding at scan.autosecurelogin.com behind a secure sign-in; checked on 2026-09-02 it answered as service version 0.3.2 and redirected an anonymous visitor to the sign-in gate. The read-only collector for Windows and Linux is deployed at version 0.5.0 with dated deployment and rollback records from 2026-08-11, and a scheduled self-assessment runs daily against ASL's own systems. The active-attack tier is deployed at thirty-three technique families as a command that stays inert without a signed authorization, an explicit authorization flag, and an emergency stop file. Delivery today is an ASL-run authorized engagement rather than a self-serve signup: the workspace is ASL's internal analyst surface, and the documented pre-conditions for hosted multi-customer use are still open.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Scan.
Aegis
Aegis is the always-on host defense that watches for and pushes back on attacks. ASL Scan's active-attack tier is built to test exactly whether a defense like it actually contains an attacker, not just logs one.
Network Sentinel
Sentinel tells a client who is on their network right now; ASL Scan tells them whether each machine is hardened. Presence plus posture answers both questions a client asks.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-08-23 , records that hold explicitly rather than leaving it as an unfinished upload. On.
Recent progress.
2026-08-13 a self-hosted purple-team suite and an operator draft-assist helper were folded into the source, and the active-attack tier was broadened to thirty-seven technique families in source and validated locally - all three remain source-only and are not deployed; the deployed tier is still thirty-three families at collector version 0.5.0. Earlier in the month a genuine fail-open gap was closed: eleven signed rules had been returning "unknown" forever because the engine collected none of the values they asked about, so a run could report zero failures while measuring nothing. An evidence-import path now carries those measurements in and fails closed on stale or unprovenanced data, and the scheduled cycle now fails a run outright when every applicable rule comes back unknown.
Recent progress.
Pricing for ASL Scan is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
We already run a vulnerability scanner. Why add this?
Most scanners answer "what might be wrong." ASL Scan answers two questions they usually skip: were you authorized to look at these exact machines, and can you prove the report wasn't edited after collection. It's read-only and needs no broad-privilege agent, so it sits alongside what you already run rather than replacing it.
Does it need an agent or our admin passwords?
No. The check runs on the machine it's measuring and reads only settings. It never asks for or touches passwords, never opens files or data, and never runs a command sent from a server. There's nothing left installed afterward. That's a deliberate choice so an assessment can't turn into the incident.
What happens to the data it collects?
The evidence keeps counts and yes/no facts - is the firewall on, is disk encryption active - not the underlying content. No passwords, no tokens, no file contents, no network addresses. What you hand a client is a posture record, not a bundle of their secrets.
How is a "signed scope" different from just having permission in an email?
The authorization is cryptographic and the tool enforces it. It names exact hosts and an expiry, and the check refuses to measure anything outside that list or after it expires. An email can be misread or stretched after the fact; a signed scope can't be quietly widened.
What if an "unknown" is really just fine?
An unknown means the check couldn't measure that control - a missing tool, a permission, an unsupported platform. It stays unknown on purpose, and your analyst decides whether a compensating control applies and documents it. Hiding an unmeasured control behind a green pass is exactly the failure this product refuses to make.
Is it ready to use, or still being built?
The analyst workspace is live behind a secure sign-in, and the read-only collector for Windows and Linux is deployed and runs a scheduled self-assessment daily on our own systems. It's delivered as an ASL-run authorized engagement rather than a self-serve signup, and the heavier active-attack tier stays gated for owner-approved disposable systems.
Do we get a login to the portal?
Not today. The workspace is where our analysts issue scopes, import evidence, and review results; what you receive is the reviewed report and the sealed evidence bundle. A customer-facing portal is not open yet, and we'd rather say so than imply a login you won't get.
What does it cost?
The business-audit engagement is a custom quote, priced on the number of targets, how much evidence is involved, the techniques in scope, regulatory context, access, travel, and reporting and retest obligations. There's no published per-seat price because two engagements are rarely the same size.
If we stop working with you, do we lose our reports?
The reports and sealed evidence bundles are files you keep. Retention is defined per engagement, and a sealed bundle stays verifiable on its own - its fingerprints can be re-checked offline, so you don't need our workspace running to prove a past report is the one that was collected.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
It is not a compliance certification. It measures hardening controls and can map results to public frameworks, but it never certifies HIPAA, PCI, or any standard, and a passing check is not proof a system is free of every flaw.
What should I know before I rely on it?
The review workspace is ASL's internal analyst surface, not a customer login. Clients receive reviewed reports and sealed evidence bundles; there is no customer portal, no finding-assignment workflow, and no evidence-deletion screen yet.
What should I know before I rely on it?
On Linux the remote-login policy is read from configuration files, which is a moderate-confidence view; an unusual setup may need a deeper effective-configuration check to confirm.
What should I know before I rely on it?
Fully hosted, self-serve use for outside customers is not open yet. Hardware-backed keys, separated roles, encrypted per-customer evidence, independent review, and legal sign-off are documented pre-conditions still ahead; today it is delivered as an authorized engagement.
What should I know before I rely on it?
The active-attack tier and the self-hosted purple-team suite issue real traffic and are for owner-owned disposable systems only. They are not pointed at a live production system without separate written authorization.
What should I know before I rely on it?
The deployed active-attack tier covers thirty-three technique families. A broader thirty-seven-family version and the purple-team suite exist in source and have passed local validation, but they are not deployed and should not be sold as running today.
What should I know before I rely on it?
The Android companion is built and signed but not on the Play Store. Only offline evidence review works today; its remote status and run-control features wait on the sign-in client and gateway being switched on.
What should I know before I rely on it?
A human review is required before any report goes to a client. The platform is deliberately not a push-button machine that sends a client a verdict on its own.
Prove the posture. Prove you were allowed to look.
Prefer email? contact@autosecurelogin.com