Private corporate batches, live online cohorts and 1-on-1 mentoring in static code analysis across a dozen languages, from translation and scan tuning to CI gating — 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 Fortify around the translate-then-scan model rather than around the user interface, because nearly every bad scan result is a translation problem. Sessions cover language-specific translation for JVM, .NET, C and C++, JavaScript and legacy stacks, build integration with Maven, Gradle and MSBuild, filter sets and rule-pack tuning, FPR optimisation and long-scan monitoring, and the Audit Workbench and IDE workflow that decides which findings reach a developer — with scans run live against real builds so failures are diagnosed rather than described.
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 Fortify that means a trainer who has run it in production — static code analysis across a dozen languages, from translation and scan tuning to CI gating — 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 Fortify batchFortify is an application security testing platform whose core is Fortify Static Code Analyzer — a static analysis engine that reads source code, builds a model of how data moves through it, and reports weaknesses such as injection, unsafe deserialisation, hardcoded credentials and path traversal without running the program. Around that engine sit Software Security Center for storing and triaging results, Audit Workbench for reviewing them, ScanCentral for distributing scans, and IDE and CI plugins that put findings where engineers already work.
The Fortify analysis is a two-stage process, and understanding that split is most of the skill. First comes translation: the build is intercepted or replayed so that Fortify sees exactly the sources, dependencies, compiler flags and generated code the real compiler sees, producing an intermediate model in a build session. Then comes the scan, which runs analysers over that model and writes results into an FPR file. A scan that misses vulnerabilities has almost always failed at translation rather than at analysis, which is why the language-by-language translation rules matter more than any dashboard.
What Fortify is used for in practice is gating and evidence. Teams wire Static Code Analyzer into Maven, Gradle, MSBuild or a raw command-line build, publish FPR files to Software Security Center, apply a filter set and a performance-tuned configuration so scans finish inside a pipeline window, and fail the build on newly introduced issues above an agreed severity. The findings that remain are audited in Audit Workbench, suppressed with a recorded rationale where they are false positives, and tracked as a security backlog rather than a one-off report.
Static analysis stopped being an annual exercise the moment delivery became continuous. A scan that takes six hours and is read by one person a quarter cannot influence code that ships daily, so the value of the tool now depends entirely on whether someone can make it run fast, run in the build, and produce findings developers accept.
Fortify remains one of the two or three static analysis platforms that show up in enterprise and regulated environments, largely because of language breadth — JVM, .NET, C and C++, JavaScript, Ruby, COBOL, ABAP, Apex, mobile — and because auditors recognise it. That breadth is also why teams struggle: every language has its own translation rules, and a team that knows how to scan Java often produces empty or misleading results the first time it points Fortify at C++ or at a JavaScript monorepo.
The scarce skill is the operational half. Configuring translation correctly for a real build, tuning filters and rule packs so the finding count is credible, keeping long scans inside a pipeline budget, optimising FPR size, and running an audit process where suppressions are justified and reviewed — that is what organisations pay for, and it is not in the product documentation in any usable order.
What the components are and which one you actually need. Static analysis as dataflow, control flow and semantic analysis over a code model; what that catches, what it cannot catch, and how Fortify findings map to the weakness taxonomies auditors ask about.
Topics: Introduction to the Fortify component set · Static Code Analyzer, Audit Workbench, Software Security Center and ScanCentral · How dataflow, control-flow and semantic analysers reason about code · Source, sink and taint propagation · What static analysis cannot detect · Rule packs, categories and severity · Mapping findings to CWE, OWASP and regulatory categories
Getting a working installation before anything else. System requirements and sizing, installer options, licence handling, security content updates, and confirming the toolchain works with a known-good scan before pointing it at a real codebase.
Topics: Fortify software system requirements and sizing · Static Code Analyzer installation, silent and scripted installs · Licence files and activation · Security content and rule-pack updates · Directory layout, logs and the build session store · Verifying the install with a known-vulnerable sample · Common installation failures and their symptoms
The lifecycle everything else hangs from. Clean, translate, scan, and the artefacts produced at each stage. Build IDs, the build session, the FPR file and what is inside it — plus how to tell a translation problem from an analysis problem by reading the logs.
Topics: Analysis process overview and the four phases · Build IDs and managing build sessions · What the FPR file contains · Reading translation and scan logs · Distinguishing translation failures from scan failures · Incremental and quick-scan modes · Where results go and how they are compared over time
The two most common enterprise stacks, and the two that most often produce misleading results. Classpath and source version handling for Java, application-server and framework considerations, and the MSBuild-driven translation path for .NET including generated code.
Topics: Translating Java code: sources, classpath, source version · JSP, framework and application-server considerations · Handling generated and annotation-processed sources · Translating .NET code and the MSBuild integration · Assemblies, references and mixed-language solutions · Verifying which files were actually translated · Common causes of under-coverage in JVM and .NET scans
Compiled and legacy code, where translation must observe the real build. Wrapping the compiler and linker for C and C++, handling preprocessor and include complexity, and the distinct translation rules for COBOL, ABAP and other languages that appear in long-lived estates.
Topics: Translating C and C++ by intercepting the compiler · Include paths, preprocessor definitions and conditional compilation · Cross-compilation and unusual toolchains · Translating COBOL code and copybook handling · Translating ABAP code and extraction from SAP · Translating other supported languages · Verifying coverage where no source tree maps cleanly to modules
The languages where there is no compiler to intercept. JavaScript and Node projects with dependency directories that should not be scanned, Ruby applications, mobile platforms, and the Salesforce and Flex stacks that still appear in enterprise portfolios.
Topics: Translating JavaScript and TypeScript projects · Excluding dependency and build directories without losing coverage · Translating Ruby code and gem handling · Translating code for mobile platforms · Translating Apex and Visualforce code · Translating Flex and ActionScript · Scan scoping for monorepos and multi-language repositories
Making scanning part of the build rather than a separate ritual. Touchless integration with existing build tools, the sourceanalyzer command line in depth, and the supporting utilities for managing build sessions, merging results and manipulating FPR files.
Topics: Integrating into a build without modifying application build files · Maven, Gradle, MSBuild and Ant integration paths · The sourceanalyzer command-line interface and key options · Command-line utilities for FPR merge, extract and information · Managing build sessions across agents · Property files and configuration precedence · Scripting a repeatable scan for a build agent
Making the output credible. Filter files and filter sets, rule-pack selection, custom rules for framework-specific sources and sinks, configuration options that change analyser behaviour, and the Scan Wizard for generating a starting configuration quickly.
Topics: Filtering the analysis with filter files and filter sets · Selecting and disabling rule packs · Custom rules for in-house frameworks and sanitisers · Configuration options and property precedence · The Scan Wizard and what to change in its output · Sample files as a regression check for rule changes · Measuring the effect of a tuning change objectively
The module that decides whether scanning survives contact with CI. Memory and thread settings, the quality-versus-speed trade-offs the analyser exposes, reducing FPR size, and monitoring a scan that has been running for hours so you know whether to wait or intervene.
Topics: Performance guide fundamentals and hardware sizing · Memory, heap and thread configuration · Performance improvement techniques for large codebases · Scan quality versus scan time trade-offs · Optimising FPR file size · Monitoring long-running scans and reading progress output · Deciding when to split a scan versus tune it
Turning a result file into decisions. The Audit Workbench workflow, evidence review through the dataflow trace, triage states and suppression discipline, and pushing the same view into the developer's editor through the Eclipse, IntelliJ and Visual Studio integrations.
Topics: Fortify Audit Workbench layout and the audit workflow · Reading a dataflow trace and confirming exploitability · Triage states, analysis tags and custom tagging · Suppression with a recorded rationale, and reviewing suppressions · Fortify plugins for Eclipse · Fortify plugins for IntelliJ, WebStorm and Android Studio · Fortify extension for Visual Studio · Security Assistant for on-the-fly feedback while typing
Operating the programme. Publishing results to Software Security Center, distributing work with ScanCentral, gating a Jenkins pipeline on new issues rather than total count, and a structured approach to the failures you will meet in the first month.
Topics: The Fortify Jenkins plugin and pipeline steps · Publishing FPR results and comparing against a baseline · Gating on new issues above a severity threshold · Software Security Center projects, versions and roles · ScanCentral for distributing translation and scan work · Troubleshooting: empty scans, memory failures, licence errors, timeouts · Best practices for rolling scanning out to a second and third team
We rebuild the agenda around the tools you actually run.
Request a custom agendaTranslate a multi-module JVM build, then reconcile translated files against the repository and fix every gap before scanning.
Intercept an existing make-based C++ build to capture compiler invocations, resolve include paths and produce a scan with real coverage.
Apply filter sets, adjust rule packs and add a custom sanitiser rule, then measure the change in true and false positives against a known result set.
Profile a slow scan, apply memory, thread and scope changes, optimise the FPR, and document exactly what depth was traded for time.
Audit a real FPR in Audit Workbench, apply consistent triage states and prove a second auditor reaches the same conclusions from your rationale.
Wire scanning into Jenkins, publish to Software Security Center, baseline the existing debt and fail the build only on newly introduced critical 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 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.
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.
| 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.