Sonatype Trainer

What each product does and where it sits, taught against the threat and compliance model that justifies it. This module deliberately separates repository administration from supply-chain governance — one serves artifacts, the other decides which artifacts are allowed to exist in your organisation.

Topics: The product family: Nexus Repository, Lifecycle, Repository Firewall, SBOM Manager · Repository administration versus component governance — different problems, different owners · The open-source consumption threat model: typosquatting, namespace confusion, maintainer compromise · Regulatory drivers: component inventory, licence obligations, provenance evidence · Sonatype's role in the Maven Central and OSS Index ecosystem · Where each product enforces, and what none of them can catch · Building the business case with numbers you can actually measure

• Assignments: (1) Map your current open-source consumption path from developer request to production, marking every uncontrolled point; (2) Write a threat statement covering the three supply-chain attacks most relevant to your stack
• Capstone: Produce a governance target-state note: which control belongs at which point in your delivery path

The data layer everything else depends on, and the part most evaluations skip. How components are identified, why that identification matters more than the vulnerability feed, and what the intelligence covers beyond CVEs — licence obligations, component age, popularity and maintenance signals.

Topics: Coordinate matching and its blind spots: shading, renaming, vendoring, rebuilds · Binary fingerprinting and identifying components by contents · The component data model: coordinates, hashes, licences, vulnerabilities, quality signals · Vulnerability data beyond raw CVE feeds — severity context and reachability · Declared versus observed licences, and multi-licence components · Component age, popularity and maintenance as risk signals · OSS Index and publicly available component data · Reading an Application Composition Report accurately

• Assignments: (1) Scan a fat JAR or bundled artifact and find components that coordinate matching alone would miss; (2) Take one reported vulnerability and trace it to the exact transitive path that introduced it
• Capstone: Produce a component inventory for one real application, with every finding attributed to a dependency path

Standing the platform up in a way that reflects how the organisation is actually shaped. Installation and configuration, authentication against a corporate directory, and the organisation and application hierarchy that determines how policy inherits — a structure that is painful to change later.

Topics: IQ Server installation, configuration file and sizing · Licensing, upgrades and data retention · Authentication: local users, LDAP and SAML single sign-on · Role-based access control and who may waive a violation · Organisations, applications and the inheritance model · Application categories and labels as policy selectors · Onboarding applications at scale rather than one at a time · Backup, restore and high-availability considerations

• Assignments: (1) Design an organisation hierarchy that matches your real team and ownership structure; (2) Wire authentication to a directory and grant waiver rights to the correct group only
• Capstone: Deliver a deployed IQ Server with a hierarchy, access model and onboarding process for new applications

The module that determines whether the platform helps or gets disabled. Policies, constraints and conditions and how they compose; threat levels and what they should mean in your organisation; inheritance from the root organisation downward; and actions calibrated per stage so that a warning becomes a failure only where it should.

Topics: Policy anatomy: policies, constraints, conditions and how they evaluate · Threat levels and mapping them to a meaningful severity scale · Security policies: severity, age of disclosure, availability of a fixed version · Licence policies: obligation categories, copyleft handling, unknown and multi-licence cases · Architectural quality policies: component age, popularity, transitive depth · Inheritance from root organisation to organisation to application · Actions per stage: no action, warn, fail — and choosing where each belongs · Starting from the reference policy set and diverging deliberately

• Assignments: (1) Author a policy set expressing your organisation's real risk appetite, not the defaults; (2) Evaluate a policy change against historical scans before enabling it
• Capstone: Deliver a documented policy set with a rationale for every threshold and every failing action

Putting policy where engineers meet it. The stage model from proxy through develop, build, stage release, release and operate; IDE feedback before a dependency is committed; CI evaluation with actionable failure output; and continuous monitoring of what is already released.

Topics: The stage model and mapping stages onto your actual pipeline · IDE integration and giving developers a verdict before they commit · CLI evaluation and the scanner's inputs — what to point it at for accurate results · CI integration with Jenkins, GitHub Actions, GitLab CI and Azure Pipelines · Build failure semantics: what a developer sees and what they can do about it · Remediation guidance and the version graph for choosing a safe upgrade · Continuous monitoring of released applications and newly disclosed vulnerabilities · Alerting and routing findings to the team that owns them

• Assignments: (1) Add evaluation to a real pipeline at two stages with different actions and compare developer experience; (2) Remediate one genuine finding using the version graph, then prove the fix in a re-evaluation
• Capstone: Wire one application end to end: IDE, build, release gate and continuous monitoring, with findings routed to owners

The only control in the family that prevents rather than reports. Quarantine at the proxy repository stops a component before it enters the organisation, which matters most for the attacks that execute at install time. Also covers auditing what is already sitting in your repositories.

Topics: Quarantine at the proxy: how it works and what a developer sees when it triggers · Protection against malicious packages, typosquats and namespace confusion · Release integrity and detecting components that changed after publication · Firewall policy versus application policy — different scope, different tuning · Auditing components already present in existing repositories · Handling a quarantine event: triage, release or block, and communication · Measuring what has been prevented, and reporting it honestly

• Assignments: (1) Configure quarantine on a proxy repository and observe a blocked request from the build side; (2) Audit an existing repository and produce a prioritised remediation list
• Capstone: Deliver a firewall configuration with a documented quarantine triage and release procedure

The compliance-facing side. Generating CycloneDX documents that are accurate rather than merely present, ingesting SBOMs supplied by vendors, tracking licence obligations to the point where legal can act on them, and producing reports that answer the questions auditors and customers actually ask.

Topics: CycloneDX structure and the fields that carry real weight · Generating SBOMs from builds versus from finished artifacts · Ingesting third-party and vendor-supplied SBOMs · VEX and communicating exploitability rather than mere presence · Licence obligations: attribution, source disclosure and copyleft boundaries · Legal review workflow and evidence retention · Reporting: trend over time, exposure by application, mean time to remediate · Answering a customer or auditor questionnaire from platform data

• Assignments: (1) Generate an SBOM for one application and validate it against the schema and against reality; (2) Produce a licence obligation report and identify one component with an obligation you are not meeting
• Capstone: Deliver an SBOM and licence obligation package for one application that a customer could accept

The organisational module, and the one that decides success. Baselining before enforcing, phasing thresholds, assigning ownership, running a waiver process that is defensible, and tracking metrics that show progress rather than a fixed backlog.

Topics: Baseline first: measure the existing estate before any action fails a build · Phased enforcement — warn, then fail on new violations, then fail on all · Grandfathering existing findings without losing sight of them · Waivers: scope, expiry, approver and the audit trail · Ownership: who fixes a finding, and routing it there automatically · Exception budgets and preventing waivers from becoming the default path · Metrics that matter: new violations per release, remediation time, waiver expiry · Integrating with Nexus Repository so governance and distribution reinforce each other

• Assignments: (1) Design a 90-day phased enforcement plan with explicit thresholds at each step; (2) Define a waiver policy with scope, expiry and approver, and process one real request through it
• Capstone: Deliver a rollout plan with baseline, phasing, ownership model, waiver process and reporting cadence