Two of the biggest breaches most people can name started somewhere other than the victim's network. They started at a vendor, a supplier, or a piece of software the victim had installed and trusted.
Week 6 covers the three programs that deal with that reality, and they are the three programs that consume most of a working security team's week.
Why Your Vendors Are Your Problem
When you connect a vendor to your systems, you inherit their security posture. That is not a moral claim, it is a technical one. Their access is access. Their credentials work on your systems. Their software runs with your permissions.
Regulators and customers have caught up with this. Most serious contracts now include security requirements, and most audit standards have a supplier section. That is why vendor management shows up as CIS Control 15 and as a control family in nearly every framework.
Running a TPRM Program
A third party risk program has four moving parts: knowing which vendors you have, tiering them by how much damage they could do, assessing the ones that matter, and re-checking on a schedule.
Tiering is where most programs live or die. If every vendor gets the same 300 question questionnaire, nobody fills it in properly and nobody reads the answers. If the coffee supplier gets a light touch and the payroll provider with domain access gets a real assessment, the program is useful.
The full method is in our third party risk management guide.
The Tool Landscape and a Real Assessment
The course walks the tooling landscape rather than selling one product. On the questionnaire and workflow side there are platforms such as OneTrust, Prevalent, and Venminder. On the outside-in ratings side there are SecurityScorecard and Bitsight.
Ratings tools are useful and frequently oversold. They see what is visible from the internet, which is real information but is not the same as knowing whether a vendor's internal controls work. You practice reading one critically instead of treating a letter grade as a verdict.
Then you run an actual assessment against a vendor scenario and write the risk decision, including what you would require in the contract.
Vulnerability Management From Scan to Fixed
A scan is not a program. The program is the loop: discover assets, scan them, triage the findings, assign an owner, fix or accept, verify, and measure how long the whole cycle takes.
You look at the common scanners, including Tenable Nessus, Qualys, and Rapid7 InsightVM, and at how CVSS scores are used and misused. A CVSS 9.8 on a lab box with no network path matters less than a CVSS 6.5 on an internet facing server holding customer data.
That prioritization problem is covered further in the vulnerability management guide, including how KEV and EPSS data change the ranking.
Asset Management, The Foundation Everything Sits On
Every control in every framework quietly assumes you have a list of your stuff. Patch management assumes it. Monitoring assumes it. Incident response assumes it. Almost nobody has it.
The reason is that assets arrive from many directions: procurement, cloud consoles, developer accounts, personal devices, acquisitions, and shadow IT. A single source of truth requires reconciling several imperfect sources, which is unglamorous work that nobody volunteers for.
You learn how to build one anyway, by combining network discovery, endpoint agents, cloud API queries, and identity provider data, and by accepting that the list is never finished. See asset management for the longer version.
Learn This at HackRange
Vendor risk and vulnerability management are two of the most commonly advertised entry level security roles. Both are covered here with real assessments rather than theory.