VAPT with the Safeguard CLI: Network, Device, Wi-Fi and AD Scans

To run an internal vulnerability assessment on the networks, devices, Wi-Fi and Active Directory you are responsible for, get written authorisation that names the targets, the time window and the people involved before anything touches the wire. Then put that scope somewhere your tooling can enforce it, run discovery from inside each segment you are assessing, and treat every result as a work item with an owner, a fix and a retest. The scan is the easy part; the authorisation, the triage and the retest are what make the exercise defensible to an auditor, a customer or your own leadership.

This post is written for the security or IT engineer who has been asked to "do a VAPT" on the internal estate and wants to do it properly and safely. The first two thirds work with whatever tools you already have. Then it shows how the Safeguard CLI's VAPT scans handle the network, device, Wi-Fi and Active Directory parts, with commands copied exactly from Safeguard's docs. Those commands were not run for this post.

Key takeaways

• Authorisation comes first and must be written: targets, exclusions, window, vantage points and who can stop the test.
• Vulnerability assessment (discovery, posture review, known CVE matching) and penetration testing (a person validating impact) are different jobs. Most programmes need both.
• Run each scan from the right place: network and device scans from inside the segment, the Wi-Fi scan on site with a wireless adapter, the directory review from a machine that can reach a domain controller.
• Results only matter once they have an owner, a fix or a documented exception, and a retest that proves the fix.
• Safeguard's VAPT scans (CLI) are GA. They run from the Safeguard CLI (GA) on a machine you control, refuse targets outside your authorised scope, and upload only results to your console as projects.
• Triage happens in the console's Findings and Vulnerabilities views (GA), with risk acceptances, workarounds and false positives recorded as Mitigations (GA).
• Policies and gates (GA) apply one of three actions to a failed policy: Block, Warn or Notify. Exceptions go through an approval workflow.

The situation

The request arrives in a few shapes. An auditor wants evidence of internal scanning and wireless monitoring. A customer questionnaire asks when you last assessed your internal network and directory. A new office comes online with printers, cameras and badge readers nobody inventoried. Or leadership wants to know what an intruder on the guest Wi-Fi could see.

Whoever asks, it lands on the security engineer or IT lead who owns the network and the directory, with a short deadline and no budget for an outside firm at every site.

A bad week looks like this. Someone runs a sweep without telling the network team, and monitoring pages the on-call engineer. A fragile label printer stops responding and has to be power cycled. A range in the target list turns out to belong to the building's Wi-Fi provider. The Wi-Fi survey flags several networks with your company's name, and nobody knows which are yours. The directory findings go into a spreadsheet, and nothing changes until the next audit asks the same question.

Every one of those failures is avoidable with planning that takes an afternoon. The rest of this post is that plan.

The rules behind it

This section summarises the rules that shape an internal assessment. It is not legal, regulatory or audit advice. If your organisation is regulated, your counsel, compliance team or assessor decides what applies to you.

Authorisation is the first control

In the United States the Computer Fraud and Abuse Act, at 18 U.S.C. 1030, turns on access "without authorization" or that "exceeds authorized access". Active scanning asks systems to respond, and in a shared building, a colocation facility or a cloud environment, not every address you can reach is yours. Written authorisation from someone entitled to grant it separates an assessment from an incident. State laws and contracts with landlords and providers can add conditions.

The practical rule: if you cannot point to a signed document that lists a target, do not scan it.

NIST SP 800-115: the testing playbook

NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, is still the most widely cited public playbook for this work. It splits techniques into review techniques, target identification and analysis techniques (network discovery, port and service identification, vulnerability scanning and wireless scanning), and target vulnerability validation techniques, which is where penetration testing sits. It treats planning, execution and post-testing activities as phases of equal weight, and it includes a rules of engagement template in its appendices.

Two of its points matter most for an internal programme. First, the rules of engagement should be written and approved before testing, and they should name the targets, the techniques, the timing and the contacts. Second, the assessment is not done when the tool finishes. Post-testing work, meaning analysis, mitigation recommendations and reporting, is part of the job.

NIST SP 800-53 Rev. 5: RA-5 and CA-8

Two NIST SP 800-53 controls carry this work. RA-5, Vulnerability Monitoring and Scanning, asks you to scan on a defined frequency and when new vulnerabilities are reported, analyse the results, remediate legitimate vulnerabilities in line with an assessment of risk, and share what you learn. CA-8, Penetration Testing, asks for penetration testing on defined systems at a defined frequency, and CA-8(1) calls for an independent agent or team. Wireless has its own controls, including AC-18, Wireless Access, and SI-4(14), Wireless Intrusion Detection. RA-5 is about finding and fixing known weaknesses across the estate; CA-8 is a focused test of whether they can be used. The scans in this post serve RA-5 style work and do not replace CA-8.

NIST CSF 2.0 and the CIS Controls

CSF 2.0 says the same thing in outcome language: ID.AM-01 expects inventories of hardware the organisation manages, and ID.RA-01 says vulnerabilities in assets are identified, validated and recorded. The CIS Controls give the order: Control 1 is the inventory of enterprise assets, Control 7 is continuous vulnerability management, Control 12 is network infrastructure management and Control 18 is penetration testing. You cannot assess what you have not inventoried, and penetration testing sits on top of routine vulnerability management, not in place of it.

PCI DSS, if you handle card data

If any part of the estate is in scope for PCI DSS v4.0, requirement 11 governs this work. Requirement 11.2 covers identifying and monitoring wireless access points, including detecting unauthorised ones. Requirement 11.3 covers internal and external vulnerability scanning, and 11.4 covers penetration testing with a defined methodology. Read the current version of the standard from the PCI Security Standards Council for the exact frequencies and testing procedures; your assessor will hold you to that text, not to a summary.

CISA's Known Exploited Vulnerabilities catalogue

CISA's Known Exploited Vulnerabilities catalogue lists vulnerabilities with evidence of exploitation in the wild. Federal civilian agencies are bound by CISA's directives (BOD 22-01 is revoked and superseded by BOD 26-04, which sets risk-based timelines), but anyone can use the catalogue as a free prioritisation signal. A KEV match on a widely reachable service goes to the top of the list.

Active Directory guidance

Control of Active Directory is control of the domain. The joint guidance Detecting and Mitigating Active Directory Compromises, developed by the Australian Signals Directorate's ACSC with CISA, NSA and other partners and published on CISA's site, recommends strategies against the techniques most commonly used to compromise it. For defenders the theme is configuration hygiene: who holds privileged rights, which accounts are stale or overprivileged, which legacy settings remain enabled, and whether changes are logged and watched. A read-only posture review shows those settings without changing them.

What these rules ask of an internal VAPT pass

Vulnerability assessment or penetration test: where these scans sit

People say "VAPT" as one word, which hides a real difference. A vulnerability assessment finds and records weaknesses: hosts, open ports, service versions, known CVEs, weak wireless encryption, risky directory settings. It is broad, repeatable and safe to run on a schedule. A penetration test asks whether those weaknesses can be used and chained into real impact. It is narrow, judgement heavy and done by a skilled person under tight rules of engagement.

Safe connect sweeps, wireless surveys and read-only directory reviews sit on the assessment side, which is the right posture for something you run often across your own estate. When an auditor or customer asks for a penetration test, plan a separate engagement with a qualified tester and hand them the assessment results as a starting point.

Step by step: an authorised internal VAPT pass, with or without Safeguard

These steps work with any tooling. Each one has a reason grounded in the rules above.

1. Name a sponsor and an owner

The sponsor is the person with authority to approve testing of the systems in scope: usually the CIO, the CISO or the head of IT. The owner is the person who runs the pass and answers for it. Write both names down. If the sponsor cannot approve a particular range, because it belongs to a subsidiary, a tenant or a provider, it is out of scope until someone who can approve it signs.

2. Write the authorisation

Keep it short and specific. A one or two page document signed by the sponsor is enough for internal work. Use this template and adjust it to your organisation.

The out-of-scope line matters as much as the in-scope one: "no exploitation, no password guessing, no changes" makes the boundary clear to everyone.

3. Build the target list from your inventory

Start from your asset inventory, IP address records and directory, not an old address plan. Mark anything that is not yours to test:

• Ranges owned or operated by a landlord, a managed service provider or an internet service provider.
• Shared infrastructure in a colocation facility.
• Cloud provider address space, which is governed by the provider's own testing policy.
• Systems run by a vendor under contract, such as a building management system or a payment terminal network, unless the contract allows testing.
• Fragile or safety-relevant equipment: medical devices, industrial controllers, lab instruments, anything that a vendor says must not be scanned.

Put fragile equipment on a separate list and agree a gentler approach with its vendor, often passive observation or a supervised maintenance-window test.

4. Encode the scope where your tools can enforce it

A signed document stops a careful person. A scope file that the scanner reads stops a tired person typing the wrong range at six in the evening. Whatever tool you use, prefer one that can refuse targets outside a declared scope, and keep that scope file next to the signed document, with the same targets.

5. Pick the vantage point for each scan

Where a scan runs from changes what it sees.

If you want to know what a guest or a contractor could see, run a second pass from the guest network or contractor VLAN as well. The difference between the two passes is a finding in its own right.

6. Tell the people who will notice

Security monitoring, network operations and the help desk will all notice. Send them the dates, hours, source machines and the owner's contact details before the window opens. It also lets you separate your scan traffic from a real attacker's in the logs afterwards.

7. Start small and stay reachable

Run each scan first against one known host or a small range. Check that results make sense, nothing fell over and results landed where expected, then widen. Stay reachable during the window; if a device stops responding, stop, record it and add it to the fragile list.

8. Collect results in one place

Every result should carry the scan type, target, vantage point and time. Keep network, device, Wi-Fi and directory results with your other vulnerability data so the same triage and reporting apply.

9. Triage

For each finding, decide: is it real, is it ours, how bad is it here, and who fixes it. Use the questions in the reading guide below. Record false positives and accepted risks with a reason, an approver and an expiry date, rather than deleting them.

10. Fix

Most fixes in an internal assessment are configuration or lifecycle work: close a port, disable a legacy protocol, upgrade firmware, change a default credential, move a device to its own network, remove a stale account from a privileged group. Assign each one to the team that owns the system, with a due date that reflects how bad it is.

11. Retest and close

A finding is closed when a rescan from the same vantage point no longer shows it. Keep the before and after results. That pair is the evidence an auditor wants, and it is the only proof that the fix worked.

Pre-flight checklist

• Signed authorisation with targets, exclusions, techniques, windows and stop conditions.
• Scope file matches the signed targets.
• Fragile and third-party systems excluded, with reasons.
• Vantage point chosen and tested for each scan.
• Notification sent to monitoring, network operations and the help desk.
• First run against a small known target succeeded.
• Results destination tested and access limited to the people who need it.
• Triage owner and fix owners agreed before the full run.

How to read the four kinds of results

Each scan type produces a different kind of result and calls for a different kind of fix. This guide works whatever tool produced the results.

Network results: ports, services, versions and CVEs

A network result has three layers: exposure (a host answers on a port), identity (the service and version on it) and known weakness (CVEs for that version, plus named checks). Read them in that order.

• Should this port be open at all? Many of the most useful findings are not CVEs. A database answering on a user VLAN, a management interface reachable from the guest network, a file share open across segments: each is a design problem, and the fix is a firewall rule or a service that should not be running.
• Is the version right? A service version with a known CVE needs an upgrade or a vendor patch. Check whether the detected version is accurate; banners can be stale or deliberately vague.
• Is the CVE known to be exploited? Check the CISA KEV catalogue. A KEV match on a reachable service is urgent.
• Who can reach it? The same CVE matters more on a service every workstation can reach than on one only a jump host can reach.

Typical fixes: disable the service, restrict it to the hosts that need it, upgrade or patch, replace legacy protocols with encrypted ones, and segment the network.

Device results: inventory first, then exposure

The device scan's first value is the inventory itself. Compare the devices it finds with your asset list. Anything on the network that is not on the list is a finding, even if it has no vulnerabilities, because you cannot patch or monitor what you do not know about.

Then read the exposure. Printers, cameras, conference room systems, smart TVs, badge readers and network storage often ship with default credentials and management services switched on. A finding that a device exposes a weak-default service usually means one of three things: the default credential was never changed, a management interface is reachable from where it should not be, or the device runs firmware old enough to have known problems.

Typical fixes: change defaults, update firmware, disable services you do not use, and put Internet of Things devices on their own network segment with only the access they need. Some devices cannot be fixed; for those, isolation and a documented exception are the honest answer.

Wi-Fi results: open networks, weak encryption and possible rogues

A wireless survey lists the networks visible from where you stand and how each is protected. Three kinds of result matter.

• Open networks. If one of your networks is open, it should be a deliberate guest network, isolated from internal systems. If it is not deliberate, close it.
• Weak or legacy encryption. WEP and legacy WPA are obsolete; the Wi-Fi Alliance describes WPA3 as mandatory for Wi-Fi CERTIFIED devices. For corporate networks, 802.1X enterprise authentication with per-user credentials or certificates beats one shared passphrase. Plan a migration for anything still on legacy modes, including the devices that keep them alive.
• Possible rogue or evil twin networks. A network broadcasting a name like yours might be an attacker's evil twin, an employee's travel router, a forgotten access point, or simply a neighbour with a similar name. Treat it as a question, not a verdict.

For a possible rogue: check your wireless controller to see whether it is yours, walk the site if it seems to be on your premises, and involve facilities and legal before doing anything about a network that is not yours. Never connect to, interfere with or disrupt a network you do not operate. Your job is to protect your users, which usually means stopping your devices from auto-joining look-alikes and using authentication an impostor cannot fake.

Directory results: identity posture

A read-only directory review looks at how the directory is configured and who holds what. It does not test passwords and does not change anything. The kinds of issue public guidance tells defenders to look for include:

• Privileged groups with more members than the job needs, or members nobody can explain.
• Accounts that are stale, disabled but still privileged, or tied to people who have left.
• Service accounts with broad rights, old passwords or settings that let their credentials be abused.
• Delegation settings that give a system more trust than it needs.
• Legacy authentication protocols and unsigned or unencrypted directory traffic still allowed.
• Policies that allow passwords never to expire or weak password settings.
• Gaps in auditing, so changes to privileged objects would go unnoticed.

Typical fixes are housekeeping: remove unneeded privileged memberships, disable then delete stale accounts, move service accounts to managed account types where your platform supports them, tighten delegation, require signing and encryption on directory traffic, and audit privileged changes. Make the changes in small batches through your change process.

Do we need written authorisation to scan our own network?

Yes. It proves the person running the scan was allowed to, which matters if something breaks or an investigation follows. It forces someone to check the boundaries, where the surprises are: provider ranges, tenant networks, devices under vendor contract. And it tells the people watching the traffic to expect it. A signed one-page scope is cheap; explaining an unapproved scan is not.

Is a read-only Active Directory review enough?

It is enough to find configuration and membership problems, and those are where most directory risk sits. It is not a test of whether an attacker could actually move through your environment, and it does not test password strength. Pair a regular read-only review with a periodic penetration test by a qualified, authorised tester who can validate the paths that matter most. The read-only review is what keeps the directory clean between those tests.

How often should we rerun?

On a schedule your risk assessment sets, and after significant changes: a new site, a network redesign, a directory migration, a merger. If a standard you are held to sets a frequency, that is the minimum, not the target. The most useful habit is to rerun the specific scan that found a problem as soon as the fix is in, so every finding gets a retest rather than waiting for the next full cycle.

How Safeguard does this

Safeguard's VAPT scans (CLI) are GA. Per Safeguard's docs, they assess infrastructure you own (networks, devices, wireless, the identity directory, and also your public footprint and cloud accounts, which have their own pages), run from the Safeguard CLI (GA) on a machine you control, and upload only their results to your Safeguard console, where they appear as projects next to your other findings. This post covers the network, device, Wi-Fi and Active Directory scans. Every command below is copied from docs.safeguard.sh exactly as shown there, and none of them was run for this post.

1. Install the CLI and sign in

The VAPT overview page gives the install command for macOS and Linux:

curl -fsSL https://cli.safeguard.sh/install | bash

The CLI overview page gives the Windows equivalent:

irm https://cli.safeguard.sh/install.ps1 | iex

Then sign in so results upload to your console:

safeguard login

The docs say the CLI provisions the tools each scan needs on first use, so you do not install them by hand. Install it on the vantage point machines you chose earlier.

2. Record your authorisation

The docs are explicit that VAPT scans actively probe systems, so the CLI requires you to confirm you are authorised to scan the target. There are two ways to do that:

• Pass --i-am-authorised on the command, or
• Place an authorising scope.yaml in .safeguard/ in your working directory that lists the targets you are permitted to scan.

Targets outside your authorised scope are refused, and the docs repeat the rule that matters most: only scan assets you own or have explicit written permission to test.

The flag suits a single known host on a first run. The scope file is the better habit for a full pass, because it turns the targets in your signed authorisation into something the CLI enforces; keep it under change control next to the signed document. The docs do not show the file's format, so take it from the CLI's help or from Safeguard rather than guessing. Neither option replaces the signature: the flag records that you claim authorisation, the document proves it.

3. Run the network scan

The network scan, per the docs, discovers open ports on a host or network range you own, identifies the services and versions listening on them, and checks the live services against known CVEs and a set of named high-profile vulnerability checks. Run it from a machine inside the target network.

Scan a single host or a CIDR range:

safeguard network-scan --targets scanme.example.com --i-am-authorised
safeguard network-scan --targets 10.0.0.0/24 --i-am-authorised

Discover and scan everything reachable on the machine's local networks:

safeguard network-scan --all --i-am-authorised

The docs describe --all as a whole-network sweep that still requires authorisation, can be slow on large or quiet subnets, and respects scope exclusions. Use --targets for the first small run. The docs list three common options:

What comes back, per the docs: each open service becomes an asset with its port, protocol and detected version; CVEs and misconfigurations found on the live services appear as vulnerabilities; and the named high-profile checks that were evaluated appear as checks with a pass or fail outcome. For the fullest results the docs recommend a machine with unfiltered network access to the target.

4. Run the device scan

The device scan, per the docs, discovers the devices on your local network and assesses their exposure. It performs a safe connect sweep, passively identifies devices, and makes a best-effort classification of each device's vendor, so weak-default or exposed services surface as findings. The docs state that it does not send exploit payloads. Run it from a machine on the local network you want to inventory.

Sweep the auto-detected local network:

safeguard device-scan --i-am-authorised

Scan a specific range:

safeguard device-scan --targets 192.168.1.0/24 --i-am-authorised

What comes back: each discovered device as an asset, with its address, open ports and detected vendor where available, plus findings for weak-default or exposed services. Compare the assets with your inventory first.

5. Run the Wi-Fi scan

The Wi-Fi scan, per the docs, enumerates the wireless networks visible from your location and assesses their posture. Open networks, networks using weak or legacy encryption, and possible evil-twin networks surface as findings. It runs on site, on a machine with a wireless adapter, and uses the operating system's own wireless tools, so no special driver setup is needed.

safeguard wifi-scan --i-am-authorised

What comes back: findings for open networks, weak-encryption networks (the docs give WEP and legacy WPA as examples), and possible rogue or evil-twin networks in range. One detail in the docs is worth knowing: if the platform's wireless tooling is unavailable, the scan reports the capability as unavailable rather than returning a silent clean result. An empty result and an unavailable scan are different things, and the CLI says which one you got.

The docs also say to assess only wireless environments you are responsible for. The scan will list neighbours' networks too; your authorisation covers your own networks and look-alikes of them, nothing else.

6. Run the Active Directory scan

The Active Directory scan, per the docs, performs a read-only review of your directory's identity posture. It queries Active Directory or LDAP for common identity and configuration weaknesses without making any changes, and it does not modify directory objects or accounts. It needs network access to the directory and, where required, read credentials.

safeguard ad-scan --ad-url ldap://dc.example.internal --i-am-authorised

What comes back: findings for identity-posture issues discovered in the directory. The docs do not list the individual checks, so read each finding's detail rather than assuming which of the review areas above it covers. Use a dedicated, read-only account for the scan, store its credential the way you store other service credentials, and give the directory URL for the environment you administer.

7. Find the results in your console

Each scan registers a project in your console and uploads its findings and any discovered assets. Open the project to review results in the usual Findings, Vulnerabilities, Assets and Checks views, next to your code and container findings.

If you prefer to start from the console, the docs describe a second route: on the Integrations page, under the Add Project/Product tab, search for a scan such as "Network Scan". Each card opens a panel with the exact command to copy and run, with your target filled in. You still run that command yourself, on your own machine.

8. Triage in Findings and Vulnerabilities

The Findings view (GA) lists each issue with its title, type, severity, status, affected component, the gate that caught it if any, and when it was first seen. You can filter by severity, type, status, gate and component. A finding's detail view carries a summary, impact, evidence, recommendations, references and history. From there you can resolve it, mitigate it, suppress it, assign it to a team member or export it. Statuses are Open, Resolved and Mitigated.

A practical order: unknown assets first, then KEV matches and high-severity CVEs on reachable services, then weak defaults and legacy encryption, then directory issues by privilege level.

9. Record exceptions as Mitigations, not deletions

Some findings will not be fixed this cycle. Mitigations (GA) let you record why. Safeguard's docs describe risk acceptance (with expiry dates), false positives, workarounds such as network controls or other compensating controls, and not-applicable records, with an audit trail. A device that cannot be patched but sits on an isolated segment is a workaround with a compensating control. A detected version that turns out to be wrong is a false positive. Write the reason, and set an expiry on every risk acceptance so it comes back for review.

10. Hold the line with policies and gates

Policies and gates (GA) are how you turn "fix it" into a rule. In Safeguard, each policy has one action, and it decides what a failed policy does to its gate:

Per the docs, Notify fires when a policy goes from passing to failing and again when a failing policy finds new matches, and an Error is never counted as a pass. When a legitimate exception is needed, someone requests it, approvers are notified, and it is granted or denied with its history kept. Approval runs through that exceptions workflow, not through a separate gate action.

Notify suits a new class of finding you want to hear about. Warn suits a standard you are moving towards. Block suits a release gate where a known critical issue should stop the release until it is fixed or an exception is approved. Check which products and gates your VAPT projects belong to before you rely on a gate for them.

11. Send fixes to the teams that own them

If your teams work from tickets, the Jira integration (GA) creates issues for findings and keeps their status in sync. Infrastructure fixes are usually done by network, desktop and identity teams who live in a ticket queue, not in a security console, so routing findings there is often what gets them fixed.

12. Rescan and keep the evidence

After a fix, rerun the same scan from the same vantage point. The project keeps the history, so the before and after results sit together. That pair, with the signed authorisation and the mitigation records, is the evidence pack for an auditor or a customer questionnaire.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not authorise you. The --i-am-authorised flag and the scope file are confirmations you make. They do not check whether you actually have permission, and they cannot stand in for a signed document from someone entitled to grant it.
• It does not exploit or validate findings. The device scan is a safe connect sweep with no exploit payloads, and the directory scan is read-only. Whether a finding can be used to cause real harm is a question for a penetration test by a qualified person.
• It does not test passwords. None of the scans in this post guesses or cracks credentials. Password strength in your directory needs its own, separately approved process.
• It does not fix infrastructure for you. Closing ports, updating firmware, changing wireless security and cleaning up the directory are your teams' changes, made through your change process. These scans find and track; people fix.
• It does not see beyond its vantage point. A network scan sees what the machine running it can reach. A Wi-Fi scan sees what is in radio range of where you stand. Segments, sites and floors you do not scan from are not assessed.
• It does not decide what a possible rogue network is. A possible evil twin is a lead. Confirming it, locating it and deciding what to do are your job, and anything involving a network you do not operate needs your legal team.

Common mistakes

• Scanning before the signature. "It's our network" is not an authorisation. Get the sponsor's signature first, every time.
• Leaving fragile devices in scope. One unresponsive medical or industrial device can end the programme. Exclude them and plan separately.
• Running everything from one laptop on the user VLAN. That shows one view of the network. Run from inside each segment you care about, and from the guest network if you want an outsider's view.
• Treating every look-alike network as an attack. Many are travel routers, neighbours or forgotten access points. Investigate before escalating, and never interfere with a network you do not operate.
• Fixing the directory in one big change. Privileged group cleanups break things. Make small, reviewed changes with a rollback plan.
• Deleting findings you will not fix. Record them as risk acceptances or workarounds with an approver and an expiry. Deleted findings come back on the next scan with no history.
• Never retesting. A fix without a rescan is a claim, not evidence.

FAQ

Can the Safeguard CLI run network scans?

Yes. Safeguard's VAPT scans (CLI), which are GA, include safeguard network-scan, which finds open ports, identifies services and versions, and checks them against known CVEs and named checks. It takes --targets or --all and requires authorisation.

Does the Safeguard Wi-Fi scan need special drivers or hardware?

Per the docs, it needs a machine with a working wireless adapter, on site, and uses your operating system's own wireless tools, so no special driver setup is required. If the platform's wireless tooling is unavailable, the scan says so rather than returning a clean result.

Does the Active Directory scan change anything in my directory?

No. The docs describe it as read-only: it queries Active Directory or LDAP and does not modify directory objects or accounts. It needs network access to the directory and, where required, read credentials.

Is the device scan safe to run on a network full of printers and cameras?

The docs describe it as a safe connect sweep that does not send exploit payloads. Any active scan can still upset a fragile device, so exclude anything safety-relevant or vendor-restricted, start with a small range, and run inside an agreed window.

What happens if I try to scan a target outside my scope?

Per the docs, targets outside your authorised scope are refused. You authorise either with --i-am-authorised on the command or with a scope.yaml in .safeguard/ in your working directory that lists permitted targets.

Where do VAPT results show up in Safeguard?

Each scan registers a project in your console. Open it to see the Findings, Vulnerabilities, Assets and Checks views, the same views used for your other projects.

Do these scans count as a penetration test for compliance?

No. They are vulnerability assessment. Standards that require penetration testing, such as NIST SP 800-53 CA-8 or PCI DSS requirement 11.4, expect a test by a qualified tester. Use the scan results as input to that engagement.

Can I block a release on a VAPT finding?

Safeguard policies apply Block, Warn or Notify when they fail, and exceptions go through an approval workflow. Whether a gate evaluates your VAPT projects depends on how your products and policies are set up, so check before relying on it.

Related reading

• How to scope a penetration test and define rules of engagement
• NIST 800-53 CA-8: penetration testing
• Penetration testing vs vulnerability scanning
• PCI DSS 11.4 penetration test requirements in plain terms
• Wi-Fi certificates vs shared passwords: 802.1X
• What is an evil twin Wi-Fi network and how to spot one

The scans above find what is wrong on the infrastructure you run: open services, old firmware, weak wireless and untidy directories. Many of the service versions they flag are built from open source components, and for the software you build and ship yourself, the question of how fast a fixed version reaches production is the same one this section answers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The Safeguard CLI demo is a real terminal session: the CLI is asked to fix a lodash CVE in a repository, reads the finding and the advisory, edits package.json, runs the install and tests with approval, and pushes nothing. Since CLI v11.10.0 it asks before any command that changes something, not before every command. The demo does not show the VAPT scans, but it is the same CLI you install for them, and the same habit of reviewing before anything changes.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up the runner on your own machine, approving it with its device code, and then scanning from the terminal. It does not show a VAPT scan, but it shows the same pattern: work runs on a machine you control and only results go to the console.

Click through it at your own pace, or open it full screen.

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. Once your VAPT projects are in the console, questions such as which findings are still open can be asked from there in plain language, subject to the tools you allow.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: VAPT Scans (CLI)
• Safeguard docs: Network Scan
• Safeguard docs: Device Scan
• Safeguard docs: Wi-Fi Scan
• Safeguard docs: Active Directory Scan
• Safeguard docs: Safeguard CLI
• Safeguard docs: ESSCM integrations
• Safeguard docs: Findings
• Safeguard docs: Mitigations
• Safeguard docs: Policies and gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Jira integration
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• NIST SP 800-53 Rev. 5
• NIST Cybersecurity Framework 2.0
• NIST SP 800-153, Guidelines for Securing Wireless Local Area Networks
• 18 U.S.C. 1030, Cornell Legal Information Institute
• CIS Critical Security Controls
• CISA Known Exploited Vulnerabilities Catalog
• CISA: Detecting and Mitigating Active Directory Compromises
• PCI Security Standards Council document library
• Wi-Fi Alliance: Wi-Fi CERTIFIED WPA3

Get the CLI at safeguard.sh/download and read the full docs at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.