from Brightleaf Supplier Readiness by Security Done Easy

Security readiness for suppliers who are ready for bigger contracts.

Hello, and welcome.

This week’s theme is patch proof.

Not “we update our systems.” Not “our IT person handles that.” Patch proof means you can show a buyer that you know which systems matter, which updates are urgent, who checked them, what was fixed, and what still needs attention.

That matters because buyers are moving away from vague security promises. They want evidence that a supplier can make practical risk decisions before an old flaw turns into a customer problem.

When a customer asks about vulnerability management, they are asking how you find, prioritize, and fix known security weaknesses. A vulnerability can be a missing software update, an exposed internet-facing system, an outdated browser, an old firewall version, a risky plugin, or a business application that no one has reviewed in months.

The point is not to prove that every system is perfect. The point is to prove that you have a repeatable way to decide what must be fixed first.

CISA issued Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” on June 10, 2026, and the directive tells federal civilian agencies to prioritize fixes based on real-world risk rather than treating all vulnerabilities and systems the same (Wiley). The directive does not directly apply to federal contractors, but CISA directed agencies to review contracts so contractors that support or operate agency systems can help agencies comply (Wiley).

That is a signal suppliers should notice. Even when a buyer does not use the exact same rule, the buyer-side question is likely to sound familiar: “How do you know which security updates are urgent?”

Start with a simple table. It can be a spreadsheet, a document, or a section in your security evidence folder.

Pick your first five systems:

For each one, write down the last update check, whether anything is overdue, and what proof you can keep.

Keep evidence that shows both action and judgment:

If you can show those five pieces of evidence, you are already answering the buyer’s real question: “Can we trust you to notice and act when something changes?”

Remember — always keep security notes, evidence, etc., secure — you don’t want to leave a roadmap to your systems and security out in the open for some miscreant to find.

Buyers do not expect every small supplier to have an enterprise vulnerability team. They do expect the supplier to know what is exposed, what is business-critical, and what cannot wait.

They are trying to understand whether your business can recognize urgent risk. A vulnerability on a test laptop is not the same as a vulnerability on a public customer portal. A browser update on a staff laptop matters, but a flaw on an internet-facing remote access tool may need a faster response.

CISA’s new risk model focuses on four questions: whether the asset is publicly exposed, whether the vulnerability is known to be exploited, whether exploitation can be automated, and whether exploitation gives an attacker partial or total control of the system (Wiley).

Confidence-building answers sound like this:

Follow-up questions usually start when the answer is too vague:

Those answers may be honest, but they do not give a buyer a way to assess your process.

Avoid promising that every device is always fully patched. That is difficult to prove and often not true.

Instead, be precise. Say what you review, how often you review it, what you prioritize first, and what evidence you keep.

Buyer-side teams can help by asking for a short patch-priority explanation instead of a long enterprise control narrative. A small supplier can usually answer:

That gives the buyer useful evidence without forcing the supplier into performative paperwork.

The NSA released guidance on the Model Context Protocol, or MCP, describing it as an application-level protocol used by many AI-enabled systems to manage interactions between services and build agent workflows (NSA). The NSA warned that MCP adoption introduces security concerns around trust boundaries, agent misuse, dynamic tool invocation, implicit trust relationships, and context sharing (NSA).

In plain English: when an AI tool can connect to email, files, customer records, code, calendars, support tickets, or cloud systems, it becomes part of your security environment.

Fresh research from Varonis showed why that matters. In a test, an AI email agent forwarded AWS keys, database passwords, SSH access, and a customer export to an external Gmail account after receiving plausible email requests from an outside sender (Varonis).

Buyers are starting to ask not just “Do you use AI?” but “What can your AI tools access?”

A supplier that uses AI to draft proposals has a different risk profile than a supplier that connects an AI agent to customer files, inboxes, source code, billing systems, or support tickets.

Create an AI access record with five lines:

Ask for the AI use case, data access, and approval process. Do not start with a 90-question AI governance form if the supplier only uses AI for drafting internal notes.

The right question is: “Can this AI tool see, change, send, or expose our information?”The NSA released guidance on the Model Context Protocol, or MCP, describing it as an application-level protocol used by many AI-enabled systems to manage interactions between services and build agent workflows (NSA). The NSA warned that MCP adoption introduces security concerns around trust boundaries, agent misuse, dynamic tool invocation, implicit trust relationships, and context sharing (NSA).

In plain English: when an AI tool can connect to email, files, customer records, code, calendars, support tickets, or cloud systems, it becomes part of your security environment.

Fresh research from Varonis showed why that matters. In a test, an AI email agent forwarded AWS keys, database passwords, SSH access, and a customer export to an external Gmail account after receiving plausible email requests from an outside sender (Varonis).

Buyers are starting to ask not just “Do you use AI?” but “What can your AI tools access?”

A supplier that uses AI to draft proposals has a different risk profile than a supplier that connects an AI agent to customer files, inboxes, source code, billing systems, or support tickets.

Create an AI access record with five lines:

Ask for the AI use case, data access, and approval process. Do not start with a 90-question AI governance form if the supplier only uses AI for drafting internal notes.

The right question is: “Can this AI tool see, change, send, or expose our information?”

CISA’s BOD 26-04 applies to federal civilian Executive branch agency systems, but the supplier signal is bigger than its formal scope (Wiley). The directive says agencies should use risk factors such as public exposure, known exploitation, automation potential, and technical impact when setting remediation urgency (Wiley).

The most severe cases can require remediation within three days and forensic triage to determine whether the system was compromised before it was fixed (Wiley).

Directly, this is for federal civilian agencies. Indirectly, it matters to suppliers that support agency systems, cloud environments, managed services, software, infrastructure, or other buyer operations.

It also matters outside federal work because buyers borrow language from public-sector guidance when they update questionnaires and contract expectations.

Do not wait for a customer to ask. Build a small patch-priority record now:

If you want suppliers to act quickly, tell them what “quickly” means. Separate urgent, high-risk updates from routine updates. Give examples of evidence you will accept.

A supplier can respond faster when the buyer’s requirement is specific.

GSA says all six OASIS+ solicitations are open continuously as of January 12, 2026, with no closing date, rolling awards, and proposal evaluation generally handled in the order received, subject to resources (GSA). GSA also says offerors must review the solicitation and amendments on SAM.gov because SAM.gov postings take precedence over FAQs, websites, or prior communications (GSA).

For suppliers, that means readiness is not only a cybersecurity issue. It is an operating discipline.

If your certifications, experience records, past performance, security evidence, and proposal files are scattered, a rolling opportunity can still feel last-minute. If those records are organized, the continuous-open model becomes easier to use.

For enterprise supplier development teams, the lesson is similar: help suppliers build reusable evidence files before the opportunity window opens.

More than 30 npm packages under Red Hat’s @redhat-cloud-services namespace were compromised in a supply-chain attack, and BleepingComputer reported that the malware targeted developer credentials, cloud secrets, SSH keys, CI/CD tokens, GitHub Actions secrets, AWS credentials, Kubernetes tokens, npm and PyPI publishing tokens, Docker credentials, and .env files (BleepingComputer).

Why buyers care: if a supplier builds software, automates deployments, or manages cloud systems, secrets and build pipelines are now part of supplier trust.

Supplier move: keep secrets out of code repositories, enable secret scanning where available, rotate credentials if exposure is suspected, and document who can publish or deploy code.

More than 900 automatic tank gauge systems in the United States were found exposed online, and BleepingComputer reported that CISA, the FBI, the NSA, the Department of Energy, and other partners warned critical infrastructure organizations to secure internet-exposed systems against ongoing attacks (BleepingComputer).

Why buyers care: a supplier’s risk may include building systems, industrial equipment, fuel systems, cameras, sensors, or other connected operational technology, not only laptops and email.

Supplier move: list internet-connected operational systems, remove direct internet exposure where possible, change default passwords, restrict remote access, and monitor for unauthorized changes.

CISA added CVE-2024-21182, a two-year-old Oracle WebLogic Server vulnerability, to its exploited vulnerabilities catalog after active exploitation, and BleepingComputer reported that CISA urged private-sector defenders to patch affected systems as soon as possible (BleepingComputer).

Why buyers care: suppliers may have older portals, middleware, web applications, or hosted systems that still process buyer data.

Supplier move: ask your IT provider or hosting team for a list of internet-facing systems and the date of the last critical patch review.

CISA added CVE-2026-28318 in SolarWinds Serv-U to its Known Exploited Vulnerabilities catalog after active exploitation, and BleepingComputer reported that Serv-U provides managed file transfer and FTP capabilities for exchanging files over HTTP/HTTPS, FTP, FTPS, and SFTP (BleepingComputer).

Why buyers care: secure file transfer is often where sensitive buyer data moves between companies. Because this specific bug causes the system to crash (disrupting operations), attackers can use this for DoS attacks to distract defenders or mask other malicious footholds.

Supplier move: if you use any managed file transfer, FTP, SFTP, or file-sharing system, name the owner, confirm patching, restrict access, and include it in your buyer data handling sheet.

Short answer: Do not promise the same timeline for everything. Explain your priority model.

Many questionnaires ask for fixed timelines, such as critical vulnerabilities patched within 15 or 30 days. That can be useful, but it can also hide the real risk. An internet-facing exploited flaw may need faster action than an internal low-risk issue.

Write a short policy statement:

“We prioritize security updates based on asset exposure, known exploitation, business impact, and whether exploitation could lead to unauthorized access or control. Internet-facing systems, actively exploited vulnerabilities, and systems that process customer data receive priority review.”

Then attach your patch priority log as evidence.

Keep the current policy statement, the patch-priority log, the latest update records for key systems, and any exception notes.

A full enterprise vulnerability-management platform can wait if you are not ready for it. What cannot wait is knowing what you own, what is exposed, and how you decide what gets fixed first.

Use or adapt this language when a customer asks about security updates:

Readiness is not about having the biggest security team. It is about having a clear next step and evidence that the step happened.

This week, start with five systems. Check whether they are current. Write down what you found. Keep the proof.

That small record can make a future questionnaire much easier to answer.