Ravindra BagaleCourses & study guides मराठी Track your progress

20. Vulnerability Scanning and Assessment

20.7 Writing a Vulnerability Report

By Last updated:

Report ha tumcha product aahe. Chaan report mhanje: manager la 1 page madhe samjel, aani engineer la fix karayla sagla mahiti milel.

Structure of a professional report:

Section Contents
Executive summary 1 page, no jargon: overall risk, top 3 issues, what to do
Scope and method Targets, dates, tools, what was out of scope
Findings summary Table: ID, title, severity, affected host
Detailed findings One block per finding (below)
Appendix Raw scan files, tool versions

One finding, written properly (lab example):

ID:          MSF2-01
Title:       vsftpd 2.3.4 contains a backdoor (CVE-2011-2523)
Severity:    Critical (CVSS 9.8, verify on NVD)
Host/Port:   192.168.56.20 : 21/tcp
Evidence:    nmap -sV shows "vsftpd 2.3.4"; ftp-vsftpd-backdoor script reports VULNERABLE
             (screenshot 3)
Impact:      A remote attacker can get a root shell without any password.
Fix:         Remove vsftpd 2.3.4; install a current vsftpd from the OS repository
             or disable FTP and use SFTP (SSH) instead. Restrict port 21 in the firewall.
References:  https://nvd.nist.gov/vuln/detail/CVE-2011-2523

Why this matters for security

A scan finds problems, but only a clear report gets them fixed. Many real breaches used vulnerabilities that had been found earlier and never fixed because nobody understood the report or knew which issue came first.

Ravindra Bagale's Tip

Students write only "the system will be hacked" under "Impact". That says nothing! Write what will happen: "customers' phone numbers can be stolen" or "the website can go down". And under "Fix", give the exact step, not just "update it".

Lab

Write a short report on Metasploitable 2 using the structure above: a one-page executive summary, a findings table, and full detail for your top five findings. Save it as PDF – this is the kind of document you can show in an interview (it is your own lab, so it is safe to share).

What reviewers look for

A good finding block answers four questions: what is wrong, where, how you know, and how to fix it. The template above already does that. Add these habits:

  1. Write for two readers: a manager (summary) and an engineer (fix steps).
  2. Paste exact commands and outputs as evidence.
  3. Name the owner team for the fix.
  4. Set a retest date.

Real examples

Indian company (sample): bank auditors ask for evidence that critical findings were retested after patching. Keep the before/after scan snippets. Global: bug-bounty platforms reject vague reports. Clear steps to reproduce win both bounties and respect.

Recap

  • Evidence, impact, fix, retest.
  • Short sentences beat jargon.

Defender's worksheet (do this today)

  1. Write the lesson title and date in your notebook.
  2. List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
  3. Run one safe command or checklist item from the lesson on a lab system only.
  4. Paste the command and its output under an Evidence heading.
  5. Write one fix you would give a teammate in two sentences.
  6. Write one mistake students make with this topic and how to avoid it.

More real-world pictures

Indian workplace (sample data)

Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.

Global practice

Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.

Home and family

Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.

Connect to earlier chapters

Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.

Common mistakes

  • Skipping written permission just for a quick scan.
  • Practising on hostel or office Wi-Fi targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Teach one other person the warning from this lesson.