Private corporate batches, live online cohorts and 1-on-1 mentoring in proxy-based dynamic scanning of running web applications and APIs, automated into the pipeline — 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 ZAP as an engineering tool rather than a button: how the proxy, contexts and scope actually constrain a scan, how to authenticate against form, JSON and token-based applications including anti-CSRF handling, and why an unauthenticated scan of a single-page application usually reports almost nothing. Sessions cover the traditional and AJAX spiders, OpenAPI and GraphQL import, passive versus active scan policy tuning, alert filters and false-positive triage, the fuzzer and scripting engine, and Automation Framework plans running in CI — every part demonstrated live against deliberately vulnerable applications the attendee deploys.
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 ZAP that means a trainer who has run it in production — proxy-based dynamic scanning of running web applications and APIs, automated into the pipeline — 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 ZAP batchZAP — the Zed Attack Proxy, originally an OWASP flagship project — is an open-source tool for testing running web applications and APIs. It works as an intercepting proxy: traffic between a browser or client and the application passes through ZAP, which records every request and response, builds a tree of the discovered site, and analyses that traffic for weaknesses. Because it tests the deployed system rather than the source, ZAP finds the class of problems that only exist at runtime — missing security headers, broken access control between roles, session handling flaws, injection reachable through the actual request path, and misconfiguration in the server in front of the application.
ZAP works in two analytical modes. Passive scanning inspects traffic that already flowed and never sends anything of its own, which makes it safe to leave running against any environment. Active scanning deliberately sends crafted requests to probe for injection and other input-handling flaws, which makes it powerful and also something you only point at systems you are authorised to test. Around those sit the discovery tools — the traditional spider, an AJAX spider that drives a real browser for single-page applications, and importers for OpenAPI, GraphQL and SOAP definitions — plus manual tools for the work no scanner can do: a request editor, breakpoints, and a fuzzer.
The reason ZAP appears in delivery pipelines rather than only on testers' laptops is its automation surface. The Automation Framework describes an entire scan — contexts, authentication, discovery, scan policy, alert filters and report generation — as a YAML plan that runs identically on a laptop and in CI. Combined with the daemon mode, the packaged baseline and full-scan containers and a full REST API, that makes a repeatable, authenticated dynamic scan a normal pipeline stage rather than an annual event.
Static analysis and dependency scanning cover the code you build and the code you import, but neither of them sees the deployed system. Authentication logic, authorisation between roles, session lifetime, headers set by a reverse proxy, an old endpoint that was never removed — these exist only at runtime, and every one of them is a common finding in real assessments.
At the same time, application surface area exploded. Single-page front ends, mobile back ends and public APIs mean far more endpoints per team than a manual penetration test can cover on an annual cycle, and those endpoints change weekly. Teams responded by moving dynamic testing into the pipeline, and ZAP is the tool most of them reach for because it is open source, scriptable, container-packaged and does not require a per-seat licence for every build agent.
The skill in demand is not clicking scan. It is getting a scanner authenticated against a modern application, keeping it inside scope so it does not wander into a payment provider, teaching it to find endpoints that a spider cannot reach, tuning policies so a pipeline stage finishes in minutes, and triaging alerts to the handful that are real. Teams that skip that work end up with a scan that reports the same twelve informational alerts forever and gets switched off.
The model everything else depends on. HTTP request and response structure, cookies and tokens, same-origin behaviour, and how a proxy sits in the middle of that conversation. Then what dynamic testing can and cannot determine, and the authorisation rules that must be established before any active scan.
Topics: HTTP requests, responses, headers, cookies and status handling · Sessions, tokens and how authentication state is carried · How an intercepting proxy records and modifies traffic · Passive analysis versus active probing · What DAST catches that static analysis cannot, and vice versa · OWASP Top 10 categories as they appear in ZAP alerts · Authorisation, scope agreements and testing only systems you own
Getting traffic into ZAP cleanly, which is where most first attempts stall. Desktop, daemon and container installation, the root certificate and TLS interception, proxying browsers, mobile clients and API tools, then contexts and scope — the mechanism that stops a scan from wandering into systems you have no right to touch.
Topics: Desktop, daemon and containerised ZAP · The ZAP root certificate and trusting it correctly · Proxying browsers, mobile devices and API clients · The Sites tree, History and how requests are recorded · Contexts: definition, inclusion and exclusion regexes · Scope, protected mode and safe mode · Add-on marketplace and managing add-ons · Session files, persistence and workspace hygiene
You cannot test what you have not found, and coverage is the biggest determinant of scan value. The traditional spider and its limits, the AJAX spider driving a real browser for JavaScript applications, forced browsing for unlinked paths, and importing API definitions so endpoints are known rather than guessed.
Topics: The traditional spider: seeds, depth, parsing and its blind spots · The AJAX spider and browser-driven crawling for single-page applications · Why a spider alone under-covers modern front ends · Forced browse and wordlist-driven content discovery · Importing OpenAPI and Swagger definitions · Importing GraphQL schemas and SOAP WSDL · Seeding from recorded browser traffic and from HAR files · Measuring and improving endpoint coverage
The module that separates a useful scan from an empty one. Configuring authentication methods, defining users and verification patterns so ZAP knows when it has been logged out, handling anti-CSRF tokens, and dealing with token-based and OIDC-protected applications where a simple form login does not apply.
Topics: Authentication methods: form-based, JSON, HTTP and script-based · Users, credentials and forced user mode · Logged-in and logged-out verification patterns · Session management: cookie-based, header-based and script-based · Anti-CSRF token handling and regeneration · Bearer tokens, refresh flows and OIDC-protected applications · Testing access control between two authenticated roles · Diagnosing a scan that silently lost its session
The analysis itself. What passive rules evaluate and why they are always safe, what active rules actually send, scan policy configuration by threshold and strength, and then the harder half — reading an alert, verifying it by hand, and deciding whether it is real, informational or noise.
Topics: Passive scan rules and what they can determine from traffic alone · Active scan rules and the requests they generate · Scan policies: rule threshold and attack strength · Building a policy that fits a fixed time budget · Alert structure: risk, confidence, evidence and the offending request · Verifying an alert manually before reporting it · Alert filters for justified suppression · Handling rate limits, WAFs and targets that fight back
The work no automated rule does. Editing and replaying requests, setting breakpoints to modify traffic in flight, fuzzing parameters with generated and file-based payloads, using the encode/decode/hash tools, and extending ZAP with scripts when the built-in rules cannot express what you need to test.
Topics: The Requester and manual request replay · Breakpoints and modifying requests and responses in flight · The Fuzzer: payload generators, processors and result analysis · Encode, decode and hash utilities for token inspection · Comparing responses to detect subtle behaviour differences · Scripting engine: standalone, active, passive, proxy and authentication scripts · Writing an authentication script for an unusual login flow · The HUD for in-browser testing
Turning a session on a laptop into a pipeline stage. The Automation Framework as a YAML plan under version control, the packaged baseline and full-scan containers, the REST API for bespoke orchestration, report generation in machine-readable formats, and the operational questions of runtime budget and result comparison over time.
Topics: The Automation Framework: jobs, plans and parameterisation · Expressing contexts, authentication, discovery and policy as a plan · Baseline scan versus full scan in a pipeline · Running ZAP in daemon mode and containerised · The REST API and driving ZAP from code · Report generation: HTML, JSON, XML, SARIF and Markdown · Comparing results against a baseline and failing on new alerts only · Fitting a scan into a stage budget, and what to do when it will not fit · Feeding alerts into a vulnerability management workflow
We rebuild the agenda around the tools you actually run.
Request a custom agendaProxy a browser, a mobile client and a command-line API tool through one instance with working TLS interception, then build a context that provably excludes third-party domains.
Scan a single-page application with the traditional spider, the AJAX spider and an OpenAPI import, and evidence coverage against the application's actual route list.
Configure JSON login, bearer token session handling and anti-CSRF token regeneration, then prove the scan never dropped its session mid-run.
Triage a real alert list, reproduce each finding manually, apply alert filters to the false positives with recorded rationale and write the report you would send a developer.
Use breakpoints, the requester and the fuzzer to find a vulnerability the active scanner did not report, then write a script so the scanner finds it next time.
Express the whole scan as an Automation Framework plan in Git, run it against an ephemeral deployment in CI, compare against a baseline and fail only on new high-risk alerts.
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.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
| 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.