Private corporate batches, live online cohorts and 1-on-1 mentoring in network vulnerability scanning and management with Greenbone — targets, feeds, credentials and reporting — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches OpenVAS as the scanning half of a vulnerability management process rather than as a scanning tool in isolation. Sessions cover the Greenbone component split and where each failure actually originates, feed synchronisation and why a stale feed is worse than no scan, target and port list design, credentialed scanning over SSH and SMB and the account model it requires, scan configuration tuning against a maintenance window, quality-of-detection filtering, overrides and notes for durable triage decisions, and driving the whole thing over the management protocol from scripts — with scans run live against attendee-provisioned hosts.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For OpenVAS that means a trainer who has run it in production — network vulnerability scanning and management with Greenbone — targets, feeds, credentials and reporting — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private OpenVAS batchOpenVAS is an open-source network vulnerability scanner and the scanning engine inside the Greenbone Vulnerability Management stack. It sweeps hosts across a network, identifies which services are listening, determines the software and versions behind them, and matches what it finds against a large, continuously updated feed of vulnerability tests. The result is host-by-host, service-by-service exposure data for infrastructure — servers, network devices, hypervisors, databases, appliances — rather than for a single application.
OpenVAS is one component of a larger system, and knowing the split matters when something breaks. The scanner executes the tests. The management daemon holds targets, scan configurations, tasks, results and users, and exposes them over the Greenbone Management Protocol. A web interface sits on top for humans, while the same protocol serves scripts and automation. Behind all of it is the feed: thousands of vulnerability tests, plus CVE, CPE and advisory data, synchronised regularly — an OpenVAS installation with a stale feed reports confidently and wrongly, which is the failure people notice last.
The difference between a useful deployment and a noisy one comes down to a few decisions. Authenticated scanning, where the scanner logs into the host with SSH or SMB credentials and reads installed package versions directly, is far more accurate than remote inference and is the single biggest quality improvement available. Quality-of-detection filtering separates confirmed findings from probable ones. Overrides and notes let you record a decision about a finding so it does not have to be re-argued every week. Scheduling, delta reports and consistent target definitions turn a one-off scan into a control you can show an auditor.
Infrastructure inventories grew faster than the teams that maintain them. Cloud accounts, container hosts, network appliances, IoT and OT devices, and long-lived virtual machines all age at their own rate, and unpatched exposed services remain one of the most reliable entry points in real incidents. Periodic authenticated vulnerability scanning is now a baseline expectation in most security frameworks rather than an optional maturity item.
OpenVAS occupies the position of the credible open-source option. Commercial scanners are licensed per asset, which makes broad, frequent coverage expensive, and many organisations settle on a mixed model: a commercial platform for the regulated estate and OpenVAS for everything else, or OpenVAS as the primary scanner where budget rules it. Either way, engineers who can run and tune it properly are in demand across security operations, infrastructure and compliance teams.
What organisations struggle with is the operational reality. Deploying the stack and synchronising the feed is fiddly. Credentialed scanning requires an account model somebody has to agree to. Scan configurations that finish inside a maintenance window need tuning. And the output — thousands of results across hundreds of hosts, many of them low-quality detections — is worthless until somebody applies quality-of-detection filtering, overrides, ownership and a remediation flow. That last part is the job.
What a network scanner does and how the stack is put together. The scanner, the management daemon, the web interface, the feed and the data store — what each is responsible for, how they communicate, and why knowing the split turns most troubleshooting into a five-minute job.
Topics: Network vulnerability scanning versus application and code scanning · Greenbone component architecture and responsibilities · The scanner, the manager daemon and the web interface · The Greenbone Management Protocol as the real interface · Where the vulnerability feed fits and what it contains · Data flow from a scan request to a stored result · Scope, authorisation and scanning only networks you own
Standing it up and proving it works. Container-based and package-based deployment, initial feed synchronisation and how long it really takes, creating administrative users, certificate handling, and the health checks that distinguish a working installation from one that returns empty scans.
Topics: Container-based versus package-based deployment · Initial setup, database preparation and service ordering · Feed synchronisation: vulnerability tests, CVE, CPE and advisory data · Verifying feed currency and diagnosing a stale feed · Creating users, roles and the initial administrative account · Certificate generation and secure access to the interface · Health checks and reading service logs · Sizing, resource consumption and where scans get slow
What the scanner is actually running. Vulnerability test structure and families, how a test decides that a host is affected, the quality-of-detection concept that determines how much you should trust a result, and how CVE and CPE data relate to the tests themselves.
Topics: Vulnerability test structure, families and identifiers · How a test probes a service and decides on a match · Version inference versus confirmed detection · Quality of detection and what each level means · CVE, CPE and advisory data and how they link to tests · Feed release cadence and what changes between versions · Reading a test's description, references and remediation guidance · Local security checks and why they need credentials
Defining what gets scanned and how deeply. Target definition and host discovery, alive tests suited to networks that drop pings, port list selection and its cost in scan time, then the module that changes result quality most — credentialed scanning, and the account model your infrastructure team has to agree to.
Topics: Target definition: ranges, host lists and exclusions · Alive tests and scanning networks that suppress ICMP · Port lists: defaults, full ranges and the time they cost · Unauthenticated versus authenticated scanning accuracy · SSH credentials and the minimum privilege a scan account needs · SMB credentials and Windows scanning requirements · ESXi and SNMP credentials for hypervisors and network devices · Storing credentials safely and rotating them · Proving a credentialed scan actually authenticated
Controlling what runs and when. Scan configuration families and preferences, the trade-off between fast and thorough, task definition and alterable tasks, scheduling around maintenance windows, and distributing scan load with sensors so a large estate does not funnel through one appliance.
Topics: Scan configuration families and enabling test groups · Configuration preferences and per-test options · Fast versus deep configurations and what each drops · Safe checks and the tests that can disrupt a target · Task creation, alterable tasks and reproducibility · Scheduling, maintenance windows and scan duration control · Concurrency: hosts and tests in parallel, and resource limits · Distributing load with sensors across network segments · Diagnosing a task that runs forever or stops early
Turning thousands of results into a work queue. Reading a result and its evidence, severity scoring and why it is only an input, filtering by quality of detection, and using overrides and notes so a false positive or an accepted risk stays decided instead of returning at every scan.
Topics: Result structure: host, port, test, severity and evidence · Severity scoring and its limits as a prioritisation signal · Filtering by quality of detection to remove low-confidence noise · Contextual severity: exposure, segmentation and asset criticality · Overrides: changing severity with a recorded justification and expiry · Notes for context that should travel with a finding · Tickets and remediation tracking · Delta reports and identifying what changed since the last scan · Recognising and investigating a suspicious drop in findings
Making it a control rather than an activity. Report formats and audiences, compliance-oriented policies for configuration benchmarks, alerts that push results to other systems, and driving scans, results and reports over the management protocol so the whole cycle can run without anyone opening the interface.
Topics: Report formats and choosing one per audience · Executive summary reporting versus engineer-level detail · Trend reporting and demonstrating improvement over time · Compliance policies and configuration benchmark scanning · Alerts and pushing results to email, ticketing or a SIEM · The Greenbone Management Protocol and command structure · Scripting scans and reports with the protocol tooling · Exporting results into a vulnerability management platform · Designing the recurring cycle: scan, triage, remediate, verify
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy the full stack, synchronise every feed type, verify component health and evidence exactly which feed versions your results are based on.
Scan the same Linux and Windows hosts with and without credentials, quantify the accuracy difference and prove authentication succeeded rather than assuming it.
Build a scan configuration and port list that completes a segment inside a maintenance window, and document precisely which checks were traded away.
Filter by quality of detection, apply contextual severity, create overrides with expiry and reduce a full result set to a queue an operations team can clear.
Run two scans a change apart, produce a delta report, explain every new and every resolved finding and identify one that disappeared for the wrong reason.
Script target creation, scan execution, result filtering and report export over the management protocol, schedule it and alert on newly introduced high-severity findings.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.