A finding is a clue.
Not a fix.

Write the scan boundary before installing anything

The scanner is a building inspector. It can notice problems, but it needs permission to enter, the right rooms must be accessible, and someone still has to decide how to repair what it finds.

Record the permitted target, scanner location/source, ports, time window, scan settings, credential scope and stop conditions. Follow the provider's current testing policies. Even non-exploit scanning can load or disrupt a service; stop if the lab becomes unstable.

Start with the networking lab's SSH-only /32 access. You do not need to reopen HTTP or expose the container port to practice host assessment. A scan sees only the services reachable from its location; an unreachable port is not proof the service is patched.

1. Match the tool to the question

As checked October 2, 2026, Tenable's Essentials product page describes a free 30-day, non-commercial license for up to five IPs, delayed plugin updates and restricted reporting/export. Do not follow old “16 IPs, free forever” tutorials or assume export features exist in your edition. Verified students/instructors may qualify for its separate education offering. Check the current terms before registration; this guide does not buy or activate a product.

Current Nessus Essentials limitsNessus system requirementsScan credentials

2. Plan a small Nessus assessment

Put the scanner on an appropriate machine

Use the official installer for a supported Windows or Linux scanner host and meet Tenable's current hardware/software requirements. Windows users should use a supported native installation, not assume WSL is a supported Nessus deployment. Linux users should use the matching vendor package. Do not squeeze Nessus onto the tiny cloud VM you are assessing or provision a larger paid VM without pricing it.

Follow the vendor's installation/activation and browser-certificate instructions. Keep the scanner management interface local or restricted to an approved management path; never add a public cloud rule for its UI. Verify any certificate setup through the supported process rather than disabling certificate validation.

The scanner needs plugin/feed connectivity and local storage. Plugin availability can take time, and a delayed feed limits current detection. A local scanner still communicates with the vendor for licensing/updates. Review the product's data-handling terms before configuring or uploading findings.

Reachability is not authorization

Use the exact existing lab public IP as the single target. The scanner must originate from the currently allowed /32 source. A native Windows scanner and WSL tooling may use different VPN/proxy routes; verify the actual path. If a different source is required, make a scoped, reviewed Terraform change—not a temporary “allow everyone” rule. Do not treat the browser SSH tunnel as a transparent vulnerability-scanner network.

Configure, review, then run deliberately

1. In the available edition, create a new scan using the Basic Network Scan template. Give it a non-sensitive lab label.
2. Set Targets to the one confirmed lab IP, not a hostname with changing/shared destinations or a subnet.
3. Limit port discovery to the authorized service ports; SSH 22 is sufficient for this first SSH-only lab. Keep safe checks enabled, exclude destructive/DoS tests and use conservative concurrency. Safe checks reduce risk; they do not guarantee zero disruption.
4. For an initial uncredentialed scan, record that package/configuration coverage is limited. Do not interpret “no findings” as a complete assessment.
5. Optional credentialed assessment: follow Tenable's SSH credential guidance using a dedicated, temporary lab identity with the required permissions. Review its escalation requirements with the lab owner. Do not paste AWS credentials, your personal private key, or production passwords into a scan policy.
6. Review target and settings once more, launch manually, and monitor both the scan and the lab service. If authentication fails, correct the authorized setup rather than broadening access blindly.

A credentialed scan can inspect local package evidence that a remote banner cannot. Verify authentication/check coverage in the results; “scan completed” does not prove credentials worked. Credential management is not automated by this website or the patch playbook.

Nessus templatesTarget syntaxSafe-check settingsCredential configuration

3. Turn one finding into a decision

Read its plugin/finding ID, CVE where present, affected component, detection method, actual evidence and recommended fixed version. A severity score is one input; also consider reachability, exposed data, exploitability, business impact and compensating controls.

Ubuntu can backport security fixes without changing the upstream-looking version string as a scanner expects. Compare the complete installed package version and applicable Ubuntu Security Notice and Ubuntu backport guidance, not only a web-server banner. Investigate false positives and missing evidence; do not dismiss every result as a backport.

dpkg-query -W -f='${Package} ${Version}\n' nginx nginx-common
apt-cache policy nginx
sudo nginx -t
systemctl status nginx --no-pager

These inspections do not prove a vulnerability is fixed on their own. No finding is assumed to exist in this lesson. If Nginx is already current or the finding affects another component, do not manufacture a vulnerability or use this Nginx example as a universal remediation.

Record the decision

Choose fix, mitigation, further investigation or a documented time-limited exception with an owner. Never turn a finding list straight into administrator access, blanket OS upgrades, firewall disabling or automatic reboots.

4. Review one Ansible package change

This optional example targets only Nginx on one Ubuntu 24.04 lab. It requires an exact reviewed repository version and explicit approval. It does not create a scanner account, patch the whole OS, resolve every CVE or reboot.

1. Preserve the lab configuration/content and a recovery plan. Package maintainer scripts can restart services; schedule a maintenance window.
2. Inside the lab, deliberately refresh metadata with sudo apt update. Then inspect apt-cache policy nginx and the applicable advisory.
3. Preview the exact candidate and its dependencies with sudo apt-get --simulate install nginx=YOUR-REVIEWED-VERSION. Stop if removals, conflicts or unrelated changes appear.
4. On your laptop use the existing Ubuntu/WSL Ansible environment, verified key and one-host inventory. Save this playbook in a separate private working folder.

ansible-playbook -i inventory.ini remediate-nginx.yml --syntax-check
ansible-playbook -i inventory.ini remediate-nginx.yml \
  -e approve_patch=true -e 'reviewed_nginx_version=YOUR-REVIEWED-VERSION' --check --diff
# Only after reviewing the lab target, version, dependencies and recovery plan:
ansible-playbook -i inventory.ini remediate-nginx.yml \
  -e approve_patch=true -e 'reviewed_nginx_version=YOUR-REVIEWED-VERSION'

The example refuses package removals and does not enable downgrades. It uses existing repository metadata, but dependencies may still be updated to satisfy the selected package. Check mode previews package work and validates existing configuration; post-change service/HTTP tests require a real run. A failed check is a reason to investigate, not to ignore the error.

Retest the laptop access path too. The playbook checks host Nginx on loopback port 80, not the Docker app on 8081. If a runtime restart/reboot is required by the advisory, plan it explicitly; this recipe does not perform one. Reconcile the desired version with your other configuration automation so future runs do not conflict.

Ansible apt version and safety options

5. Trivy checks the image, not the whole environment

Optional: on a supported control machine, follow Trivy's official installation instructions. Use the same exact reviewed Python image digest from the container lab, not a different image tag that happens to share its name.

trivy image --scanners vuln --severity HIGH,CRITICAL \
  python@sha256:YOUR-REVIEWED-DIGEST

This can download the image and vulnerability database, requiring network, disk space and registry access. The filter deliberately excludes lower-severity results; it is not a complete inventory. Keep database/tool timestamps and check whether a fixed package/image is available. A digest pins content—it does not freeze the vulnerability knowledge about it.

If remediation requires a newer image, review its digest, test application behavior, and update the container recipe deliberately. Recheck that exact new digest. Updating the host's Nginx package does not patch packages inside the Python container, and an image scan does not prove the VM's IAM/firewall settings are safe.

Trivy container-image assessment

6. Rescan, preserve evidence, remove temporary access

1. Check configuration, service state and intended application behavior after the change.
2. Rescan the same authorized target with comparable scope/settings and working authentication. Record feed/tool versions and any changed coverage.
3. Verify the specific finding was resolved or explain why it remains. A lower finding count caused by lost credentials or a blocked port is not a fix.
4. Record remaining risks and planned actions. A clean report does not certify the system is secure.
5. Remove only dedicated temporary scan credentials and source-IP exceptions you created, without removing your only administrative access. Update Terraform if it owns the rule.
6. Protect or deliberately remove local reports/credentials under the product's supported workflow. License expiry may remove access/data; record permissible evidence before that point without assuming export support.
7. Clean up the original cloud lab using its guide. Stopping the scanner or finishing a scan does not stop VM charges.

Keep raw reports private: they reveal software versions, addresses, hostnames and weaknesses. Publish a sanitized finding/remediation summary, not credentials or a full exposure inventory.