Private corporate batches, live online cohorts and 1-on-1 mentoring in open source inventory, licence compliance and vulnerability management across the dependency graph — 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 Black Duck around BOM accuracy first: which detection method identifies which kind of dependency, why a package-manager-only scan misses vendored and binary code, and how to verify a bill of materials rather than trust it. Sessions cover Detect configuration inside real builds, signature and snippet scanning trade-offs, container and binary analysis, policy rules that block for a defensible reason, vulnerability triage using advisory and remediation data, and SPDX and CycloneDX export — with scans run live against real projects and the BOM corrected by hand where detection gets it wrong.
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 Black Duck that means a trainer who has run it in production — open source inventory, licence compliance and vulnerability management across the dependency graph — 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 Black Duck batchBlack Duck is a software composition analysis platform. It determines which open source and third-party components are present in an application, then reports the known vulnerabilities attached to those components and the licence obligations they carry. The output is a bill of materials for a specific build, not a general opinion about your dependencies, which is what makes it usable as evidence in an audit or a customer security questionnaire.
Identification is the hard part, and Black Duck uses several methods because no single one is sufficient. Package-manager detection reads lockfiles and dependency trees and is accurate where a manifest exists. Signature scanning hashes files and directories against a knowledge base for code that arrived without a manifest — vendored libraries, unpacked archives, copied source. Snippet matching finds fragments of open source pasted into first-party files. Binary analysis identifies components inside compiled artifacts and container images where no source is available at all. A real scan usually combines several of these, and choosing the combination is a deliberate decision with a cost in scan time.
Operationally, Black Duck is driven by Detect, the command-line scanner that runs inside a build, discovers the project type, and uploads results to the server. Findings land in a project version as a BOM, where components are confirmed or corrected, policy rules decide what constitutes a violation, and vulnerability data — including advisories that arrive before a CVE is published — drives remediation guidance. From there the same data feeds build gates, SPDX or CycloneDX SBOM exports and attribution reports for distribution obligations.
The proportion of an application that a team writes itself keeps falling. Most of what ships is transitive dependency code pulled in by a package manager, and several widely publicised incidents have made clear that a vulnerability four levels down the dependency tree is still your incident to handle.
That changed the commercial conversation. Customers and procurement teams now request an SBOM as a condition of purchase, regulated sectors expect component inventory as a control rather than a nicety, and legal teams want licence obligations identified before a product ships rather than after a distribution question arises. Composition analysis moved from a security nice-to-have to a release requirement, and Black Duck is one of the platforms that enterprise buyers and auditors already recognise.
What organisations find hard is not installing the scanner. It is producing a bill of materials that is actually correct — with the right detectors enabled, vendored code identified, container layers covered and false matches corrected — and then writing policy that blocks a release for a real reason rather than generating hundreds of violations that everyone learns to override. That is the difference between an SCA deployment and an SCA programme.
The problem before the platform. Where third-party code enters an application, why transitive dependencies dominate the risk, how vulnerability data is published and delayed, and what a licence obligation actually requires of you when you distribute software.
Topics: Direct, transitive and vendored dependencies · How vulnerability data is published: CVE, NVD and vendor advisories · Advisory data that arrives before a CVE is assigned · Open source licence families and their obligations · Copyleft, permissive and dual licensing in practice · What an SBOM is and who is asking for one · Where composition analysis fits alongside static and dynamic testing
How the platform is put together and what an administrator has to keep healthy. Server components and their roles, container-based deployment and sizing, the knowledge base and its updates, and the user, group and project-role model that controls who sees what.
Topics: Server components and their responsibilities · Container-orchestrated deployment and sizing considerations · The knowledge base and how component data is kept current · Users, groups, roles and project-level access · Authentication integration with LDAP and SAML · Job monitoring, scan queues and troubleshooting a stuck scan · Backup, upgrade and health checks
The core technical module. Package-manager detection, signature scanning, snippet matching and binary analysis compared on what each finds, what each misses and what each costs in scan time — then how to combine them so a scan is both accurate and affordable.
Topics: Package manager detection and lockfile accuracy · Signature scanning for code with no manifest · Snippet matching and when it is worth the noise · Binary analysis for compiled artifacts and firmware · Container image and layer scanning · Match types, confidence and component origins · Choosing a detection strategy per repository type
Driving scans from the tooling teams already use. Running Detect against Maven, Gradle, npm, pip and Go projects, controlling behaviour through properties and configuration files, handling private registries and offline builds, and choosing between a full scan and a rapid pre-merge check.
Topics: Detect invocation, detectors and automatic project-type discovery · Property precedence: command line, files, environment and server configuration · Excluding and forcing detectors when discovery gets it wrong · Private registries, proxies and authenticated dependency resolution · Offline and air-gapped scanning · Rapid scan for pull requests versus full scan for releases · Naming projects and versions consistently across pipelines
Turning scan output into an inventory somebody can rely on. Project and version modelling so releases are comparable, reading the BOM and its match evidence, correcting misidentified components, and handling the recurring awkward cases — forks, modified copies and internal shared libraries.
Topics: Project and version modelling, phases and distribution settings · Reading BOM entries, match evidence and component origins · Confirming, correcting and ignoring components · Handling forked and modified open source · Custom components for internal libraries · Comparing BOMs across versions and tracking drift · Verifying coverage rather than trusting the component count
The half of composition analysis that is not about vulnerabilities. Licence identification and conflicts, obligations triggered by distribution model, then policy rules: writing conditions that catch the cases you care about, setting severities, and building an exception path that does not become a permanent bypass.
Topics: Licence identification, licence families and declared versus detected licences · Obligations by distribution model: SaaS, on-premises, embedded · Licence conflicts and incompatible combinations · Policy rule conditions, severities and scope · Blocking versus warning policy outcomes · Policy violation workflow, overrides and expiry · Attribution and notice reports for distributed software
Closing the loop. Reading vulnerability records including pre-CVE advisories, judging exploitability in your context, using upgrade guidance to plan a fix that does not break the build, then exporting the evidence — SBOMs, reports and API-driven data — and gating pipelines on the result.
Topics: Vulnerability records, severity scoring and advisory sources · Contextual triage: reachability, exposure and actual exploitability · Remediation and upgrade guidance, and transitive upgrade planning · Triage states, comments and remediation tracking · SBOM export in SPDX and CycloneDX · Reports, dashboards and scheduled distribution · The REST API for custom reporting and automation · Failing a pipeline on policy violation and communicating it to developers
We rebuild the agenda around the tools you actually run.
Request a custom agendaScan the same project with package manager, signature, snippet and binary detection, then explain every difference in the resulting component lists.
Wire Detect into Maven, Gradle and npm builds behind a private registry, using property files rather than ad-hoc flags, and add a rapid pre-merge scan.
Take a scan with vendored code, forked libraries and misidentified components, and correct it into an inventory you could hand to an auditor.
Write policy rules for licence and vulnerability conditions, prove each fires on a real project, and design an exception path with an expiry.
Scan a container image layer by layer, separate base-image components from application dependencies, and decide which team owns each finding.
Produce a verified BOM for a release, export it as SPDX and CycloneDX, generate an attribution report and gate the pipeline on the policy result.
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.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
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.
| 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.