Security scanning scope defines which systems and services an assessment may test, which techniques it may use, and under which conditions. A discovered hostname or resolved IP address is evidence of a technical relationship. Before sending test traffic, establish who can authorize that particular assessment, which exclusions apply, and who can pause it when the destination or permission changes.

That distinction matters when your company name appears in traffic reaching someone else's server. A tool can discover a real relationship and still draw the wrong boundary around the testing you commissioned.

On September 13, a volunteer time-server operator [reported unexpected security-testing traffic](https://dreamstation.systems/personal/tesla.html) carrying a Tesla hostname and Assetnote-related identifiers. The operator suggested that a DNS alias into a shared time-service pool might explain the targeting, explicitly presenting that explanation as speculation. The page now says Assetnote contacted the operator and the matter was resolved. It does not establish a vendor-confirmed root cause or a successful compromise.

The useful question for your team is broader than that account: **what evidence turns a discovered asset into an authorized scan target?** The framework below is our operational recommendation, illustrated with fictional assets. It is a way to review your own process, not a finding about either company's internal controls.

## What does security scanning scope actually cover?

An assessment needs a boundary around the service being tested and the actions permitted against it. An asset list alone leaves the permitted actions unclear.

Consider a fictional company, Example Works, with an application at `app.example.com`. Your application team may control its code and customer configuration while a provider operates the network underneath. Permission to test the application does not settle whether the assessment may probe unrelated services at the same address, test another customer's tenant, or run disruptive techniques.

Write the scope so an assessor can answer three questions without guessing: what may receive traffic, what may happen to it, and what event requires a pause? Include the relevant environment and account identity. A production application and its staging copy can have different owners, data, and operating constraints even when their names look similar.

[NIST SP 800-115, section 6.5](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf), describes assessment planning that covers permitted and excluded systems, testing activities, logistics, data handling, and incident procedures. It also addresses third-party consent and authority to resume interrupted testing. This is longstanding guidance published in 2008, not a new requirement for 2026.

Apply that principle with enough detail for the actual engagement. A narrow application review might need a short brief. A recurring assessment across changing infrastructure needs a maintained record and a way to check changes before execution. In both cases, someone should be able to explain why the next request is within scope.

## Where can a discovered hostname lead?

A hostname can identify a service you use without establishing control over everything behind it. Keep the discovery evidence, but investigate the service relationship before allowing active tests.

The following examples are fictional. They show questions to resolve, not rules that automatically approve or reject a target.

| Discovered relationship | What remains unknown | Evidence needed before testing |
| --- | --- | --- |
| `app.example.com` reaches a shared CDN | Which application routes and techniques your permission covers | Your application identity, engagement scope, and applicable provider conditions |
| `support.example.com` aliases a vendor-hosted tenant | Whether the vendor permits this assessment of your tenant | The tenant boundary and the vendor's relevant testing policy or approval |
| `time.example.com` refers clients to an external time service | Who operates the destination and can authorize testing it | The service arrangement and permission applicable to the actual operator |
| An inventory entry retains a former cloud address | Whether the resource is still assigned to your account | Current resource identity and account assignment, reconciled with the scan configuration |

Shared infrastructure is not automatically untouchable. You may have valid authorization to assess your application through a provider's edge. The boundary fails when that permission silently expands to other tenants, ports, or services merely because they share an address.

The [NTP Pool's vendor guidance](https://www.ntppool.org/en/vendors.html) describes arrangements for products using the pool as their default time service, including designated vendor hostnames. Those arrangements concern using a time service. They do not, by themselves, establish permission to security-test the volunteer machines providing it.

Keep excluded dependencies in your inventory. Your security team may still need to review their configuration, discuss assurance with the vendor, or track a replacement. Removing a service from active testing should not make the business dependency disappear from view.

## What should you record before enabling active tests?

Keep a small authorization record next to the asset inventory. Connect each asset to the permission evidence, testing constraints, and person responsible for the assessment.

Our suggested record contains the following fields. Adapt them to your engagement rather than treating them as a compliance form:

- **Service identity:** the hostname, environment, and relevant tenant, account, or resource identifier.
- **Responsible people:** the business owner, actual operator, and assessment owner.
- **Discovery evidence:** how you found the asset and what relationship that evidence establishes.
- **Permission evidence:** the approved engagement, applicable provider policy, or specific agreement, with its limits.
- **Allowed work:** technique classes, exclusions, permitted accounts, and data-handling expectations.
- **Validity conditions:** the period or circumstances covered, and which changes require review.
- **Execution reference:** the scanner configuration or assessment job that implements the approved boundary.
- **Stop contact:** who can pause the work and who can authorize its return.

Do not make every record depend on a fresh permission email. A published provider policy may already permit particular testing under stated conditions. For example, [AWS's penetration-testing policy](https://aws.amazon.com/security/penetration-testing/) distinguishes assessments of customers' own permitted infrastructure from testing AWS infrastructure or services themselves. The relevant service and conditions matter; a general reference to a cloud provider is not enough.

Use clear states so discovery cannot quietly become execution. We suggest **discovered, awaiting verification**; **verified, not authorized for this assessment**; **authorized with constraints**; and **paused pending review**. These are proposed workflow states, not built-in Kit asset states.

For Example Works' fictional support tenant, the record might remain verified but not authorized while the owner checks the vendor policy. The relationship is confirmed, and the inventory stays useful. The active assessment simply has no basis to include it yet. That is a normal outcome, not unfinished housekeeping someone should clear by clicking an approval button.

## How do you keep authorization attached to a running scan?

The running assessment must preserve the approved service boundary. Review how your tools turn hostnames, redirects, and new discoveries into executable work.

Start with the handoff from inventory to scanner. If you approve an application hostname, inspect whether the next stage tests that application or expands the job to its resolved addresses. Converting a hostname into an address can be necessary for a connection. Converting it into permission for every service at that address is a different decision.

Ask the same question about redirects and automated exploration. A link to a vendor's login page can be useful discovery information without extending the assessment to that vendor. Decide whether the tool stops, records the destination for review, or continues under an authorization that already covers it. Make that behavior visible to the person approving the run.

Infrastructure changes need proportionate review. A replacement instance inside the same authorized account and service boundary may already be covered. A new destination outside that boundary needs a decision. Do not force a manual approval for every routine address change; define which identity and ownership conditions must remain true.

Queued work deserves its own check. Removing a target from the next inventory export does not demonstrate what happens to jobs already scheduled or running. Verify how your assessment tools cancel pending work, handle retries, and apply exclusions across workers. These are questions for your scanner's implementation and configuration, not guarantees supplied by a scope document.

Retain the scope version used for each run and enough execution evidence to trace a reported request back to its assessment. Restrict access to sensitive samples. The goal is to answer a concrete question later: which approved service and permission did this job believe it was testing? A current configuration screenshot cannot explain a request sent under yesterday's settings.

## How should a mistaken-target report stop the work?

Give reports of unwanted assessment traffic a direct path to someone who can pause it. Your team should check the target even if the sender has no bounty-eligible vulnerability to report.

A disclosure contact helps people reach you. [RFC 9116, section 5.5](https://www.rfc-editor.org/rfc/rfc9116.html#section-5.5), makes clear that the presence or absence of `security.txt` does not imply permission to test. Treat the contact mechanism and authorization policy as separate things, and keep both understandable.

For the commissioning team, we recommend this response sequence:

1. **Pause the implicated work.** Identify the assessment or target closely enough to stop the reported traffic while investigating.
2. **Preserve a minimal sample.** Ask for timestamps and relevant request identifiers. Avoid circulating sensitive bodies or credentials in broad notifications.
3. **Find the assessment owner.** Connect the report to the person who commissioned the job and can change its scope.
4. **Reconcile the destination.** Check the service identity, actual operator, and permission evidence against the job that ran.
5. **Update execution as well as records.** Correct the target or exclusion and deal with queued requests, retries, and recurring schedules.
6. **Verify the stop.** Check execution records to confirm the implicated traffic ended. Where appropriate, ask the reporting operator whether their observations agree.
7. **Close the loop.** Explain what was paused or corrected, and resume only the work whose authorization is established.

Do not promise a root cause before you have checked it. A useful initial reply can acknowledge the report, identify the investigation owner, and state that the relevant assessment is paused. A later reply can distinguish confirmed findings from remaining uncertainty.

This is related to, but earlier than, [coordinating a vulnerability across several vendors](/blog/coordinated-disclosure-multi-vendor-vulnerabilities). Here the immediate task is to establish where your own commissioned traffic belongs. Any vulnerability investigation can continue under an appropriate, separately understood scope.

## How can you test the boundary without probing public systems?

Run a tabletop exercise using synthetic inventory records and a non-networking test queue. You want evidence of the decision and pause behavior before involving real external destinations.

In this proposed exercise, give one teammate the assessor role and another the service-owner role. Have them work from the records your team actually uses. Do not fill gaps for them verbally; note where they need to invent an answer.

**Change the operator.** Start with an approved fictional application, then change its record to a vendor-hosted tenant. Check whether the existing authorization covers that relationship. A pass means the team either demonstrates the applicable permission or holds the new target for review.

**Remove queued work.** Put a synthetic target in the test queue, then remove its authorization. Check pending jobs and retries as well as the next scheduled discovery. Record which mechanism prevents the withdrawn work from executing.

**Leave the approved application.** Give the exercise a synthetic redirect to a different example hostname. Ask what the assessor does next and where that decision is recorded. The engagement's boundary should determine the answer, whoever happens to be watching.

**Receive an operator complaint.** Send an internal sample report containing a fictional timestamp and request identifier. Check whether the receiving team can find the assessment owner, pause the right work, and produce a clear response without disclosing sensitive material.

Capture failures as specific changes: a missing owner, an exclusion that misses retries, or a report form that routes the complaint to the wrong queue. Then repeat the affected scenario. Success means a demonstrable response to these cases, not proof that every possible targeting error has been eliminated.

## What questions usually cause confusion about scan permission?

Technical association, contact details, and authorization answer different questions. Keep those distinctions explicit when someone asks to expand a scan.

### Does a CNAME put the destination in scope?

It establishes a DNS relationship. It does not answer who operates the destination or which tests your engagement permits there. Review the service identity and applicable permission before expanding active testing. A valid existing agreement may cover the destination; the alias alone does not establish that agreement.

### Does a public disclosure policy authorize every test?

Read its actual scope and conditions. A reporting invitation is useful, but the published terms may limit assets, accounts, techniques, or handling of data. Refer questions about unclear boundaries to the program contact before active testing. Our [program configuration guide](/docs/configuring-your-program) explains how to publish those boundaries in Kit.

### Must every provider approve every assessment individually?

No universal approval process fits every provider. Check the current policy for the relevant service and proposed work. Some testing is covered by published conditions; other work needs a separate agreement. Preserve the basis for your decision so the next assessor does not have to reconstruct it from a general vendor homepage.

## How can Kit support a clear scope and reporting process?

Your team needs a readable public policy and a reliable place to handle questions about it. The scanner also needs its own correctly implemented execution controls.

Kit's VDP portal publishes in-scope targets, out-of-scope categories, excluded vulnerability types, and disclosure policy text. It can display your program's safe-harbor wording and let researchers copy scope as Markdown. Use those surfaces to explain the permitted service boundary and where uncertainty should be raised.

The [researcher portal](/docs/the-researcher-portal) provides a submission and follow-up path. Give the people handling those reports a route to the owner of any assessment your company commissions. A report about unwanted traffic should reach someone who can investigate its source and coordinate a pause.

Publishing scope in Kit does not verify infrastructure ownership, confer permission over a third party, configure your scanner, or cancel its queued jobs. Scope settings also do not automatically reject reports outside the published boundary. Those decisions still require the relevant people and tools.

Before your next assessment, connect the published scope, permission record, execution configuration, and stop contact. Check a synthetic target change all the way through that process. The useful outcome is simple: your team can explain why a test may run, and can stop it when that explanation no longer holds.

> [!CTA]
> **Make your program's testing boundaries easy to find.** Publish scope and a reporting path, then connect incoming questions to the person responsible for your assessments.
>
> [Start your free trial](/users/sign_up)