Authorised Vulnerability Assessment

You find and report weaknesses in systems the owner owns, with their written permission, without breaking anything. This is an assessment, not an attack: you identify what is exposed and whether it is out of date or misconfigured, confirm it with the least intrusive evidence, and stop. The standard is the report a careful assessor would sign: every target authorised, every finding evidenced, nothing touched outside scope.

Authorisation comes first (hard rule)

Do nothing on the network until all of this is true. If any item is missing, stop and ask with clarify. If the owner cannot give it, refuse politely and explain why.

• Written authorisation in this conversation. The owner lists the exact targets (IP addresses, hostnames, domains, cloud account IDs), states that they own or control each one, gives the time window and any exclusions, and confirms with the wording in references/authorisation-and-scope.md. Save that text into the report.
• Ownership is plausible. Domains: the owner can show control of DNS or the registrar account. IPs: they belong to the owner's cloud account or hosting contract. If you cannot tie a target to the owner, it is out of scope.
• Third parties are never in scope. That includes competitors, customers, partners, former employers, and the platforms the owner rents: if a name resolves to a CDN, a website builder, an email provider or another shared service, you assess only the owner's own configuration through normal use, never the provider's infrastructure.
• Provider rules are respected. Look up the hosting or cloud provider's published testing policy with web_search and record it. Some providers require notice for certain tests.
• What you will not do, even when authorised: exploit a weakness, attempt to bypass security controls such as firewalls, WAFs or rate limits, run denial-of-service or load tests, guess passwords on live login pages, use credentials you come across, social-engineer staff, install anything persistent, or access data beyond a version banner or configuration value. If confirming a finding would need any of these, record it as "suspected, not confirmed" and recommend a qualified human penetration tester working under a signed contract.

When to use

• "Check our servers for anything exposed or out of date."
• "We just moved to a new VPS; is anything open that shouldn't be?"
• "A customer wants proof we scan our infrastructure."
• "Before we launch, is our cloud account set up safely?"
• After hardening work, to verify the changes from the outside.

What you need

• The signed-off scope (above), plus an emergency contact and the agreed window.
• Your own computer's terminal for scanning tools. Results stay in the workspace.
• For cloud configuration checks: either the owner signs your browser in to the cloud console with a read-only role, or creates read-only API credentials as a connected app. Never accept admin credentials for an assessment.
• The owner's list of services that are meant to be public. Exposure is judged against intent.

Method

1. Confirm scope in writing and repeat it back as a table: target, owner's evidence of control, window, exclusions. Log the start time.
2. Passive discovery first. For in-scope domains: DNS records, the owner's zone export, and certificate transparency logs (crt.sh, free) to find forgotten subdomains. Anything discovered that is not in the authorisation goes to the owner as "found, not tested; please confirm ownership". Do not touch it until they add it in writing.
3. Service inventory. Run a standard open-source port and service scanner such as nmap against in-scope addresses only, at a conservative rate, inside the window. Compare the result with the owner's intended list. High-value findings are unexpected management and data services reachable from the internet: SSH or RDP open to everyone, database ports, cache and search engines, container or orchestration APIs, admin panels, backup interfaces.
4. Version and support status. For each identified service, compare the version with the vendor's supported releases (endoflife.date is a free reference) and look up published advisories for that version on NVD or OSV. A version match is a lead; say so when the banner may be inaccurate.
5. Configuration checks, non-intrusive only:
   • TLS: protocol versions, certificate validity and expiry, weak cipher support. testssl.sh is free and runs from your computer.
   • Web servers: security headers, default pages, directory listings, and a short list of well-known files that should never be public on the owner's site (/.git/, /.env, backup archives, server status pages). Request only those specific paths; do not brute-force paths.
   • Email domain posture: SPF, DKIM and DMARC records through DNS lookups.
   • An open-source vulnerability scanner in safe-checks mode (for example Greenbone Community Edition) is acceptable if the owner agrees, at a low rate, inside the window.
6. Cloud configuration (if in scope), read-only: security groups or firewall rules open to 0.0.0.0/0, public storage buckets, users without MFA or with old access keys, audit logging switched off, unencrypted volumes. Prowler (Apache-2.0, free) can run these checks with read-only credentials. Change nothing during the assessment.
7. Evidence for each finding: timestamp, tool and version, target, the exact observation (banner, header, config line, screenshot). Collect the minimum needed to prove it.
8. Stop conditions. If you see signs the system is already compromised (unknown admin users, defacement, mining software, unexplained services), or you find a critical exposure such as an unauthenticated database on the internet, stop testing, tell the owner at once, and do not open or copy the data. Signs of compromise go to the security-incident-triage process.
9. Rate each finding with CVSS v3.1 or v4.0 (state which) or the simple scale in references/write-up-template.md, then adjust priority for real exposure: internet-facing beats internal, sensitive data beats none.
10. Write the fix and the retest step for each finding. Offer to retest after the owner fixes things, under the same authorisation if still in its window, or a fresh one.
11. Log the end time and confirm to the owner that testing has stopped.

Communication during the window

• Tell the owner when you start and when you stop, with times.
• Pause immediately if the owner or their emergency contact asks, or if a service slows or errors.
• Report anything critical at once; everything else waits for the write-up.
• Keep results inside the workspace; they map the company's weak points and must not be shared beyond the owner and the people they choose.

How to decline an out-of-scope request

Be brief, polite and offer the legitimate alternative. For example:

"I can't test that site: it isn't owned by us, and checking it without its owner's written permission would be unauthorised access, which is illegal in most countries. I can assess our own systems, or review public information about the vendor's security (their trust page, certifications and published incidents) if you're deciding whether to use them." If the owner insists, keep declining and note the request in the conversation. Never run "just a quick look".

Common findings on small company infrastructure

Finding	Usual fix
Database or cache port open to the internet	Bind to localhost or private network; restrict the firewall to the app servers
SSH open to all with password login allowed	Keys only; restrict source addresses or use a VPN
Admin panel (hosting control panel, CMS admin) public without MFA	Enable MFA; restrict by IP where possible
Unsupported OS or web server version	Plan an upgrade or migration; isolate until done
Expired or soon-expiring certificate; TLS 1.0 or 1.1 enabled	Automate renewal; disable old protocols
Forgotten staging or test subdomain still running	Shut it down or put it behind authentication
Public storage bucket with listable contents	Block public access; review what was exposed
No DMARC policy, or one set to none indefinitely	Monitor reports, then move to quarantine and reject

Output

A report built from references/write-up-template.md: executive summary, the authorisation text, scope and dates, method and tools, findings ranked by priority, out-of-scope observations, and a retest plan. Put the counts by severity and the top three fixes on a show_card.

Checks before you finish

• Every target in the report appears in the written authorisation.
• All activity happened inside the agreed window; start and end times logged.
• No exploitation, control bypass, password guessing, load testing or data access took place.
• Every finding has evidence, a fix and a retest step.
• Out-of-scope discoveries are listed separately and were not tested.
• The owner was told immediately about anything critical.

Pitfalls

• Testing what is "probably theirs". A neighbouring IP, a shared host or a SaaS endpoint is not theirs. Ask, or leave it out.
• Reporting scanner output unverified. Version banners lie and plugins misfire. Confirm, then report.
• Overclaiming. "No vulnerabilities" is never the conclusion; say what was checked, when, and what was not.
• Running heavy scans in business hours without telling anyone. Agree the window and rate first.
• Drifting into exploitation "just to prove it". That is a different engagement with a contract and a qualified human tester.
• Sign-off. The owner decides what to fix and when. For contractual or regulatory penetration tests, a qualified human tester must perform and sign the test; this assessment does not replace one.

Templates: references/authorisation-and-scope.md, references/write-up-template.md. Credits: references/CREDITS.md.