Private corporate batches, live online cohorts and 1-on-1 mentoring in The Update Framework — signed metadata, delegated trust and key compromise survival for software repositories — 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 TUF as an operational design problem rather than a specification reading: the four roles and what each one can and cannot authorise, why root keys stay offline and online keys are deliberately limited, and how version numbers, expiry and snapshot consistency map one-to-one onto the rollback, freeze and mix-and-match attacks they exist to stop. Sessions build a real repository with python-tuf or go-tuf, add delegations so teams sign only their own artefacts, run threshold signing ceremonies, and rehearse key rotation and compromise recovery until the runbook works — then place TUF alongside Sigstore, in-toto, SLSA and container signing so attendees can explain what each layer actually proves.
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 TUF that means a trainer who has run it in production — The Update Framework — signed metadata, delegated trust and key compromise survival for software repositories — 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 TUF batchTUF — The Update Framework — is a specification for securing software update and distribution systems. It is not a product you install and forget; it is a design that a repository adopts so that clients can verify what they download even when parts of the infrastructure are compromised. TUF is a graduated project of the Cloud Native Computing Foundation and underpins package distribution, container signing and cloud-native trust roots across the industry.
The central idea is separation of responsibilities across four signing roles. Root establishes the trust anchor and names the keys for every other role. Targets signs the actual artefacts and their hashes and lengths. Snapshot signs a consistent view of which metadata versions belong together, and Timestamp signs a short-lived statement that this is the current state. Each role holds its own keys, each requires a configurable threshold of signatures, and each has an expiry. Because the roles are separate, the compromise of one online key does not let an attacker replace an artefact: the online keys can only do what their role permits, and the high-value root key stays offline.
That structure defends against a specific catalogue of attacks that plain signing does not address. A rollback attack, serving an older signed version with a known vulnerability, is blocked by version numbers in signed metadata. A freeze attack, serving valid but stale metadata forever, is blocked by expiry. Mix-and-match attacks are blocked by snapshot consistency. Delegations let a repository hand signing authority for a subset of artefacts to another team or project without granting it authority over everything, and threshold signatures plus documented key rotation give TUF something most signing schemes lack — a defined path to recover after a key is lost or stolen.
Software supply chain attacks moved from theory to routine. Compromised build systems, malicious packages published under names close to real ones, hijacked maintainer accounts and tampered update channels have all produced large incidents, and the pattern is consistent: the artefact was signed, or trusted, or delivered over TLS, and none of that helped because the attacker had access to the thing doing the signing.
Regulation and procurement followed. Executive-level supply chain directives, SLSA levels appearing in vendor questionnaires, SBOM requirements in contracts and customers asking how you would recover from a signing key compromise have all made this a board-visible topic. The uncomfortable question in every one of those conversations is the same — if your signing key leaked tomorrow, what would you actually do?
TUF is the mature answer to that question, and it is already load-bearing. Python's package index adopted it, container signing implementations were built on it, Sigstore uses a TUF-managed trust root, automotive update systems use its Uptane derivative, and multiple cloud vendors ship it inside their update paths. Engineers who understand the role model, delegation design, threshold policy and key rotation procedure are rare, and they are exactly who a platform or security team needs when it is asked to prove its distribution chain is defensible.
The threat model before the framework. How software actually reaches a machine, the real attack classes against that path, and a precise demonstration of why a signature and TLS leave rollback, freeze and mix-and-match attacks wide open.
Topics: The distribution path from build to install, and every point an attacker can touch · What a plain code signature does and does not prove · Rollback, freeze and indefinite freeze attacks · Mix-and-match and dependency confusion · Endless data and slow retrieval attacks · Malicious mirrors and compromised content delivery · Key compromise as an assumed event rather than a failure · Real incident patterns and which TUF mechanism would have applied
The framework itself, read properly. The four top-level roles and their metadata files, what each signs and why the split exists, version numbers, expiry, thresholds, and the client update workflow that ties them together in a strict order.
Topics: Root: the trust anchor and key distribution for all other roles · Targets: artefacts, hashes, lengths and custom metadata · Snapshot: consistent views and preventing mix-and-match · Timestamp: freshness and short expiry · Metadata structure, signatures and canonical serialisation · Version numbers, expiry and the rollback and freeze defences · Thresholds and multi-signature requirements per role · The client update workflow and why its ordering is mandatory · Consistent snapshots and safe concurrent publishing
The part organisations get wrong. Key types and generation, hardware-backed and offline storage, threshold policy per role, who holds what, and the ceremony discipline that makes a root signing repeatable, witnessed and auditable rather than a heroic act by one engineer.
Topics: Key types, generation and secure storage · Offline root keys: hardware tokens, air-gapped machines and custody · Online keys for timestamp and snapshot, and their limited blast radius · Threshold selection per role and the availability trade-off · Separation of duties and quorum design · Signing ceremony procedure, witnesses and evidence · HSM and cloud KMS integration · Key expiry, renewal cadence and calendar discipline · What actually happens when a threshold cannot be met
Hands on the implementations. Initialising a repository with python-tuf or go-tuf, adding targets, generating and signing all four metadata roles, publishing, and verifying the whole thing from a client that starts with nothing but a root of trust.
Topics: Implementation landscape: python-tuf, go-tuf, rust-tuf, tough and repository services · Initialising a repository and generating the initial role keys · Adding, updating and removing targets · Generating, signing and publishing metadata · Trusted root distribution and client bootstrapping · Client verification, download and the local trusted metadata store · Handling metadata expiry in an automated pipeline · Repository layout, hosting and content delivery · Automating repository operations safely
How TUF works when there are a thousand artefacts and forty teams. Delegated targets roles, path patterns, terminating and non-terminating delegations, hashed bin delegation for very large repositories, and designing a hierarchy where a compromised team key cannot affect anyone else's artefacts.
Topics: Delegated targets roles and how trust is passed down · Path patterns and restricting what a delegate may sign · Terminating versus non-terminating delegations and search order · Nested delegations and depth considerations · Hashed bin delegation for very large target sets · Succinct delegations and metadata size management · Per-team and per-project signing models · Revoking a delegation and what clients see afterwards · Designing a hierarchy for blast radius rather than for convenience
The reason TUF exists. Rotating each key type, what a root rotation requires of clients, recovering from timestamp, snapshot, targets and root key compromise, expiry emergencies, and the monitoring and runbooks that make all of it a procedure rather than an incident.
Topics: Rotating timestamp, snapshot, targets and delegated keys · Root key rotation and the client trust transition · Compromise recovery per role: what an attacker could do and what to revoke · Recovering when metadata has expired in production · Handling a lost key when the threshold can still be met, and when it cannot · Monitoring expiry, version continuity and publishing health · Disaster recovery and offline backup of key material · Auditing: proving after the fact what was signed and by whom · Writing runbooks the on-call engineer can actually follow
Where it fits alongside everything else a platform team is being asked for. Container signing, Sigstore's TUF-managed trust root, in-toto attestations, SLSA levels, SBOM requirements, the Uptane automotive profile, and integrating TUF with existing artefact repositories and CI without breaking consumers.
Topics: Container image signing and the TUF-based lineage behind it · Sigstore: Fulcio, Rekor and the TUF root of trust underneath · in-toto attestations: proving how an artefact was built · SLSA levels and where TUF contributes evidence · SBOMs and what they do and do not prove · Uptane: the automotive profile and its extra roles · Integrating with existing artefact repositories and registries · CI pipeline integration and keeping signing keys out of build agents · Migrating an existing repository to TUF without breaking clients · Explaining the whole chain to an auditor or customer
We rebuild the agenda around the tools you actually run.
Request a custom agendaDemonstrate rollback, freeze and mix-and-match attacks against a plainly signed repository, then show which TUF mechanism blocks each one.
Initialise a TUF repository, generate all four role keys, sign and publish metadata, then install an artefact through a client that starts with only a root of trust.
Run a threshold root signing ceremony with independent signers, offline key handling and written evidence that would survive an audit.
Build a delegation hierarchy for three teams with non-overlapping path authority, then revoke one and prove the others still verify.
Simulate an online key compromise and execute a full recovery — revocation, rotation, republishing — from a runbook, without reinstalling clients.
Deliver build provenance, signing, TUF-secured distribution and client verification for one artefact, stating exactly what each control proves.
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.