Supply Chain Vulnerabilities - Nocturnalknight's Lair

Oracle Cloud Breach Is a Transitive Trust Timebomb : Here’s How to Defuse It

By Ramkumar Sundarakalatharan | July 15, 2025 | Comments 0 Comment

“One mispatched server in the cloud can ignite a wildfire of trust collapse across 140,000 tenants.”

1. The Context: Why This Matters

In March 2025, a breach at Oracle Cloud shook the enterprise SaaS world. A few hours after Rahul from CloudSEK first flagged signs of a possible compromise, I published an initial analysis titled Is Oracle Cloud Safe? Data Breach Allegations and What You Need to Do Now. That piece was an urgent response to a fast-moving situation, but this article is the reflective follow-up. Here, I break down not just the facts of what happened, but the deeper problem it reveals: the fragility of transitive trust in modern cloud ecosystems.

Threat actor rose87168 leaked nearly 6 million records tied to Oracle’s login infrastructure, affecting over 140,000 tenants. The source? A misconfigured legacy server still running an unpatched version of Oracle Access Manager (OAM) vulnerable to CVE‑2021‑35587.

Initially dismissed by Oracle as isolated and obsolete, the breach was later confirmed via datasets and a tampered page on the login domain itself, captured in archived snapshots. This breach was not just an Oracle problem. It was a supply chain problem. The moment authentication breaks upstream, every SaaS product, platform, and identity provider depending on it inherits the risk, often unknowingly.

Welcome to the age of transitive trust. shook the enterprise SaaS world. Threat actor rose87168 leaked nearly 6 million records tied to Oracle’s login infrastructure, affecting over 140,000 tenants. The source? A misconfigured legacy server still running an unpatched version of Oracle Access Manager (OAM) vulnerable to CVE‑2021‑35587.

Welcome to the age of transitive trust.

2. Anatomy of the Attack

Attack Vector

Exploited: CVE-2021-35587, a critical RCE in Oracle Access Manager.
Payload: Malformed XML allowed unauthenticated remote code execution.

Exploited Asset

Legacy Oracle Cloud Gen1 login endpoints still active (e.g., login.us2.oraclecloud.com).
These endpoints were supposedly decommissioned but remained publicly accessible.

Proof & Exfiltration

Uploaded artefact visible in Wayback Machine snapshots.
Datasets included:
- JKS files, encrypted SSO credentials, LDAP passwords
- Tenant metadata, PII, hashes of admin credentials

Validated by researchers from CloudSEK, ZenoX, and GoSecure.

3. How Was This Possible?

Infrastructure drift: Legacy systems like Gen1 login were never fully decommissioned.
Patch blindness: CVE‑2021‑35587 was disclosed in 2021 but remained exploitable.
Trust misplacement: Downstream services assumed the upstream IDP layer was hardened.
Lack of dependency mapping: Tenants had no visibility into Oracle’s internal infra state.

4. How This Could Have Been Prevented

Oracle’s Prevention Gaps
Vector	Preventive Control
Legacy exposure	Enforce infra retirement workflows. Remove public DNS entries for deprecated endpoints.
Patch gaps	Automate CVE patch enforcement across cloud services with SLA tracking.
IDP isolation	Decouple prod identity from test/staging legacy infra. Enforce strict perimeter controls.
What Clients Could Have Done
Risk Inherited	Mitigation Strategy
Blind transitive trust	Maintain a real-time trust graph between IDPs, SaaS apps, and their dependencies.
Credential overreach	Use scoped tokens, auto-expire shared secrets, enforce rotation.
Detection lag	Monitor downstream for leaked credentials or unusual login flows tied to upstream IDPs.

5. Your Response Plan for Upstream IDP Risk

Domain	Best Practices
Identity & Access	Enforce federated MFA, short-lived sessions, conditional access rules
Secrets Management	Store all secrets in a vault, rotate frequently, avoid static tokens
Vulnerability Hygiene	Integrate CVE scanners into CI/CD pipelines and runtime checks
Visibility & Auditing	Maintain structured logs of identity provider access and token usage
Trust Graph Mapping	Actively map third-party IDP integrations, revalidate quarterly

6. Tools That Help You Defuse Transitive Trust Risks

Tool	Mitigates	Use Case
CloudSEK XVigil	Credential leaks	Monitor for exposure of tokens, admin hashes, or internal credentials in open channels
Cortex Xpanse / Censys	Legacy infra exposure	Surface forgotten login domains and misconfigured IDP endpoints
OPA / OSQuery / Falco	Policy enforcement	Detect violations of login logic, elevated access, or fallback misroutes
Orca / Wiz	Runtime posture	Spot residual access paths and configuration drifts post-incident
Sigstore / Cosign	Supply chain integrity	Protect CI/CD artefacts but limited in identity-layer breach contexts
Vault (HashiCorp)	Secrets lifecycle	Automate token expiration, key rotation, and zero plaintext exposure
Zerberus.ai Trace-AI	Transitive trust, IDP visibility	Discover hidden dependencies in SaaS trust chains and enforce control validation

7. Lessons Learned

When I sat down to write this, these statements felt too obvious to be called lessons. Of course authentication is production infrastructure, any practitioner would agree. But then why do so few treat it that way? Why don’t we build failovers for our SSO? Why is trust still assumed, rather than validated?

These aren’t revelations. They’re reminders; hard-earned ones.

Transitive trust is NOT NEUTRAL, it’s a silent threat multiplier. It embeds risk invisibly into every integration.
Legacy infrastructure never retires itself. If it’s still reachable, it’s exploitable.
Authentication systems deserve production-level fault tolerance. Build them like you’d build your API or Payment Gateway.
Trust is not a diagram to revisit once a year; it must be observable, enforced, and continuously verified.

8. Making the Invisible Visible: Why We Built Zerberus

Transitive trust is invisible until it fails. Most teams don’t realise how many of their security guarantees hinge on external identity providers, third-party SaaS integrations, and cloud-native IAM misconfigurations.

At Zerberus, we set out to answer a hard question: What if you could see the trust relationships before they became a risk?

We map your entire trust graph, from identity providers and cloud resources to downstream tools and cross-SaaS entitlements.
We continuously verify the health and configuration of your identity and access layers, including:
- MFA enforcement
- Secret expiration windows
- IDP endpoint exposure
We bridge compliance and security by treating auth controls and access posture as observable artefacts, not static assumptions.

Your biggest security risk may not be inside your codebase, but outside your control plane. Zerberus is your lens into that blind spot.

Want to Know Who You’re Really Trusting?

Start your free Zerberus trial and discover the trust graph behind your SaaS stack—before someone else does.

JP Morgan’s Warning: Ignoring Security Could End Your SaaS Startup

By Ramkumar Sundarakalatharan | July 1, 2025 | Comments 0 Comment

The AI-driven SaaS boom, powered by code generation, agentic workflows and rapid orchestration layers, is producing 5-person teams with £10M+ in ARR. This breakneck scale and productivity is impressive, but it’s also hiding a dangerous truth: many of these startups are operating without a secure software supply chain. In most cases, these teams either lack the in-house expertise to truly understand the risks they are inheriting — or they have the intent, but not the tools, time, or resources to properly analyse, let alone mitigate, those threats. Security, while acknowledged in principle, becomes an afterthought in practice.

This is exactly the concern raised by Pat Opet, CISO of JP Morgan Chase, in an open letter addressed to their entire supplier ecosystem. He warned that most third-party vendors lack sufficient visibility into how their AI models function, how dependencies are managed, and how security is verified at the build level. In his words, organisations are deploying systems they “fundamentally don’t understand” — a sobering assessment from one of the world’s most systemically important financial institutions.

To paraphrase the message: enterprise buyers can no longer rely on assumed trust. Instead, they are demanding demonstrable assurance that:

Dependencies are known and continuously monitored
Model behaviours are documented and explainable
Security controls exist beyond the UI and extend into the build pipeline
Vendors can detect and respond to supply chain attacks in real time

In June 2025, JP Morgan’s CISO, Pat Opet, issued a public open letter warning third-party suppliers and technology vendors about their growing negligence in security. The message was clear — financial institutions are now treating supply chain risk as systemic. And if your SaaS startup sells to enterprise, you’re on notice.

The Enterprise View: Supply Chain Security Is Not Optional

JP Morgan’s letter wasn’t vague. It cited the following concerns:

78% of AI systems lack basic security protocols
Most vendors cannot explain how their AI models behave
Software vulnerabilities have tripled since 2023

The problem? Speed has consistently outpaced security.

This echoes warnings from security publications like Cybersecurity Dive and CSO Online, which describe SaaS tools as the soft underbelly of the enterprise stack — often over-permissioned, under-reviewed, and embedded deep in operational workflows.

How Did We Get Here?

The SaaS delivery model rewards speed and customer acquisition, not resilience. With low capital requirements, modern teams outsource infrastructure, embed GPT agents, and build workflows that abstract away complexity and visibility.

But abstraction is not control.

Most AI-native startups:

Pull dependencies from unvetted registries (npm, PyPI)
Push unscanned artefacts into CI/CD pipelines
Lack documented SBOMs or any provenance trace
Treat compliance as a checkbox, not a design constraint

Reco.ai’s analysis of this trend calls it out directly: “The industry is failing itself.”

JP Morgan’s Position Is a Signal, Not an Exception

When one of the world’s most risk-averse financial institutions spends $2B on AI security, slows its own deployments, and still goes public with a warning — it’s not posturing. It’s drawing a line.

The implication is that future vendor evaluations won’t just look for SOC 2 reports or ISO logos. Enterprises will want to know:

Can you explain your model decisions?
Do you have a verifiable SBOM?
Can you respond to a supply chain CVE within 24 hours?

This is not just for unicorns. It will affect every AI-integrated SaaS vendor in every enterprise buying cycle.

What Founders Need to Do — Today

If you’re a startup founder, here’s your checklist:

Inventory your dependencies — use SBOM tools like Syft or Trace-AI
Scan for vulnerabilities — Grype, Snyk, or GitHub Actions
Document AI model behaviours and data flows
Define incident response workflows for AI-specific attacks

This isn’t about slowing down. It’s about building a foundation that scales.

Final Thoughts: The Debt Is Real, and It’s Compounding

Security debt behaves like technical debt, except when it comes due, it can take down your company.

JP Morgan’s open letter has changed the conversation. Compliance is no longer a secondary concern for SaaS startups. It’s now a prerequisite for trust.

The startups that recognise this early and act on it will win the trust of regulators, customers, and partners. The rest may never make it past procurement.

References & Further Reading

InfoSec’s Big Problem: Too Much Hope in One Cyber Database

By Ramkumar Sundarakalatharan | April 16, 2025 | Comments 0 Comment

The Myth of a Single Cyber Superpower: Why Global Infosec Can’t Rely on One Nation’s Database

What the collapse of MITRE’s CVE funding reveals about fragility, sovereignty, and the silent geopolitics of vulnerability management

I. The Day the Coordination Engine Stalled

On April 16, 2025, MITRE’s CVE program—arguably the most critical coordination layer in global vulnerability management—lost its federal funding.

There was no press conference, no coordinated transition plan, no handover to an international body. Just a memo, and silence. As someone who’s worked in information security for two decades, I should have been surprised. I wasn’t. We’ve long been building on foundations we neither control nor fully understand.The CVE database isn’t just a spreadsheet of flaws. It is the lingua franca of cybersecurity. Without it, our systems don’t just become more vulnerable—they become incomparable.

II. From Backbone to Bottleneck

Since 1999, CVEs have given us a consistent, vendor-neutral way to identify and communicate about software vulnerabilities. Nearly every scanner, SBOM generator, security bulletin, bug bounty program, and regulatory framework references CVE IDs. The system enables prioritisation, automation, and coordinated disclosure.

But what happens when that language goes silent?

“We are flying blind in a threat-rich environment.”
— Jen Easterly, former Director of CISA (2025)

That threat blindness is not hypothetical. The National Vulnerability Database (NVD)—which depends on MITRE for CVE enumeration—has a backlog exceeding 10,000 unanalysed vulnerabilities. Some tools have begun timing out or flagging stale data. Security orchestration systems misclassify vulnerabilities or ignore them entirely because the CVE ID was never issued.

This is not a minor workflow inconvenience. It’s a collapse in shared context, and it hits software supply chains the hardest.

III. Three Moves That Signalled Systemic Retreat

While many are treating the CVE shutdown as an isolated budget cut, it is in fact the third move in a larger geopolitical shift:

January 2025: The Cyber Safety Review Board (CSRB) was disbanded—eliminating the U.S.’s central post-incident review mechanism.
March 2025: Offensive cyber operations against Russia were paused by the U.S. Department of Defense, halting active containment of APTs like Fancy Bear and Gamaredon.
April 2025: MITRE’s CVE funding expired—effectively unplugging the vulnerability coordination layer trusted worldwide.

This is not a partisan critique. These decisions were made under a democratically elected government. But their global consequences are disproportionate. And this is the crux of the issue: when the world depends on a single nation for its digital immune system, even routine political shifts create existential risks.

IV. Global Dependency and the Quiet Cost of Centralisation

MITRE’s CVE system was always open, but never shared. It was funded domestically, operated unilaterally, and yet adopted globally.

That arrangement worked well—until it didn’t.

There is a word for this in international relations: asymmetry. In tech, we often call it technical debt. Whatever we name it, the result is the same: everyone built around a single point of failure they didn’t own or influence.

“Integrate various sources of threat intelligence in addition to the various software vulnerability/weakness databases.”
— NSA, 2024

Even the NSA warned us not to over-index on CVE. But across industry, CVE/NVD remains hardcoded into compliance standards, vendor SLAs, and procurement language.

And as of this month, it’s… gone!

V. What Europe Sees That We Don’t Talk About

While the U.S. quietly pulled back, the European Union has been doing the opposite. Its Cyber Resilience Act (CRA) mandates that software vendors operating in the EU must maintain secure development practices, provide SBOMs, and handle vulnerability disclosures with rigour.

Unlike CVE, the CRA assumes no single vulnerability database will dominate. It emphasises process over platform, and mandates that organisations demonstrate control, not dependency.

This distinction matters.

If the CVE system was the shared fire alarm, the CRA is a fire drill—with decentralised protocols that work even if the main siren fails.

Europe, for all its bureaucratic delays, may have been right all along: resilience requires plurality.

VI. Lessons for the Infosec Community

At Zerberus, we anticipated this fracture. That’s why our ZSBOM™ platform was designed to pull vulnerability intelligence from multiple sources, including:

MITRE CVE/NVD (when available)
Google OSV
GitHub Security Advisories
Snyk and Sonatype databases
Internal threat feeds

This is not a plug; it’s a plea. Whether you use Zerberus or not, stop building your supply chain security around a single feed. Your tools, your teams, and your customers deserve more than monoculture.

VII. The Superpower Paradox

Here’s the uncomfortable truth:

When you’re the sole superpower, you don’t get to take a break.

The U.S. built the digital infrastructure the world relies on. CVE. DNS. NIST. Even the major cloud providers. But global dependency without shared governance leads to fragility.

And fragility, in cyberspace, gets exploited.

We must stop pretending that open-source equals open-governance, that centralisation equals efficiency, or that U.S. stability is guaranteed. The MITRE shutdown is not the end—but it should be a beginning.

A beginning of a post-unipolar cybersecurity infrastructure, where responsibility is distributed, resilience is engineered, and no single actor—however well-intentioned—is asked to carry the weight of the digital world.

References

Gatlan, S. (2025) ‘MITRE warns that funding for critical CVE program expires today’, BleepingComputer, 16 April. Available at: https://www.bleepingcomputer.com/news/security/mitre-warns-that-funding-for-critical-cve-program-expires-today/ (Accessed: 16 April 2025).
Easterly, J. (2025) ‘Statement on CVE defunding’, Vocal Media, 15 April. Available at: https://vocal.media/theSwamp/jen-easterly-on-cve-defunding (Accessed: 16 April 2025).
National Institute of Standards and Technology (NIST) (2025) NVD Dashboard. Available at: https://nvd.nist.gov/general/nvd-dashboard (Accessed: 16 April 2025).
The White House (2021) Executive Order on Improving the Nation’s Cybersecurity, 12 May. Available at: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ (Accessed: 16 April 2025).
U.S. National Security Agency (2024) Mitigating Software Supply Chain Risks. Available at: https://media.defense.gov/2024/Jan/30/2003370047/-1/-1/0/CSA-Mitigating-Software-Supply-Chain-Risks-2024.pdf (Accessed: 16 April 2025).
European Commission (2023) Proposal for a Regulation on Cyber Resilience Act. Available at: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (Accessed: 16 April 2025).

Do You Know What’s in Your Supply Chain? The Case for Better Security

By Ramkumar Sundarakalatharan | December 2, 2024 | Comments 0 Comment

I recently read an interesting report by CyCognito on the top 3 vulnerabilities on third-party products and it sparked my interest to reexamine the supply chain risks in software engineering. This article is an attempt at that.

The Vulnerability Trifecta in Third-Party Products

The CyCognito report identifies three critical areas where third-party products introduce significant vulnerabilities:

Web Servers
These foundational systems host countless applications but are frequently exploited due to misconfigurations or outdated software. According to the report, 34% of severe security issues are tied to web server environments like Apache, NGINX, and Microsoft IIS. Vulnerabilities like directory traversal or improper access control can serve as gateways for attackers.
Cryptographic Protocols
Secure communication relies on cryptographic protocols like TLS and HTTPS. Yet, 15% of severe vulnerabilities target these mechanisms. For instance, misconfigurations, weak ciphers, or reliance on deprecated standards expose sensitive data, with inadequate encryption ranking second on OWASP’s Top 10 security threats.
Web Interfaces Handling PII
Applications that process PII—such as invoices or financial statements—are among the most sensitive assets. Alarmingly, only half of such interfaces are protected by Web Application Firewalls (WAFs), leaving them vulnerable to injection attacks, session hijacking, or data leakage.

Beyond Web Servers: The Hidden Dependency Risks

You control your software stack, but do you actually know what runs beneath those flashy Web/Application servers?

Drawing parallels from my previous article on PyPI and NPM vulnerabilities, it’s clear that open-source dependencies amplify these threats. Attackers exploit the very trust inherent in supply chains, introducing malicious packages or exploiting insecure libraries.

For example:

Attackers have embedded malware into popular NPM and PyPI packages, which are then unknowingly incorporated into enterprise-grade software.
Dependency confusion attacks exploit naming conventions to inject malicious packages into CI/CD pipelines.

These risks share a core vulnerability with traditional third-party systems: an opaque supply chain with minimal oversight. This is compounded by the ever-decreasing cycle-times for each software releases, giving little to no time for even great Software Engineering teams to doa decent audit and look into the dependency graph of the packages they are building their new, shiny/pointy things that is to transform the world.

Why Software Supply Chain Attacks Persist

As highlighted by Scientific Computing World, software supply chain attacks persist for several reasons:

Aggressive GTM Timelines: Most organisations now run quarterly or even monthly product roadmaps, so it is possible to launch a new SaaS product in a matter of days to weeks by leveraging other IaaS, PaaS or SaaS systems – in addition to any Libraries, frameworks and other constructs.
Exponential Complexity: With organisations relying on layers of third-party and fourth-party services, the attack surface expands exponentially.
Insufficient Oversight: Organisations often focus on securing their environments while neglecting the vendors and libraries they depend on.
Lagging Standards: The industry’s inability to enforce stringent security protocols across the supply chain leaves critical gaps.
Sophistication of Attacks: From SolarWinds to MOVEit, attackers continually evolve, targeting blind spots in detection and remediation frameworks.

Recommended Steps to Mitigate Supply Chain Threats

To address these vulnerabilities and build resilience, organizations can take the following actionable steps:

1. Map and Assess Dependencies

Use tools like Dependency-Track or Sonatype Nexus to map and analyze all third-party and open-source dependencies.
Regularly perform software composition analysis (SCA) to detect outdated or vulnerable components.

2. Implement Zero-Trust Architecture

Leverage Zero-Trust frameworks like NIST 800-207 to ensure strict authentication and access controls across all systems.
Minimize the privileges of third-party integrations and isolate sensitive data wherever possible.

3. Strengthen Vendor Management

Evaluate vendor security practices using frameworks like the NCSC’s Supply Chain Security Principles or the Open Trusted Technology Provider Standard (OTTPS).
Demand transparency through detailed Service Level Agreements (SLAs) and regular vendor audits.

4. Prioritize Secure Development and Deployment

Train your development teams to follow secure coding practices like those outlined in the OWASP Secure Coding Guidelines.
Incorporate tools like Snyk or Checkmarx to identify vulnerabilities during the software development lifecycle.

5. Enhance Monitoring and Incident Response

Deploy Web Application Firewalls (WAFs) such as AWS WAF or Cloudflare to protect web interfaces.
Establish a robust incident response plan using guidance from the MITRE ATT&CK Framework to ensure rapid containment and mitigation.

6. Foster Collaboration

Work with industry peers and organizations like the Cybersecurity and Infrastructure Security Agency (CISA) to share intelligence and best practices for supply chain security.
Collaborate with academic institutions and research groups for cutting-edge insights into emerging threats.

7. Schedule a No-Obligation Consultation Call with Yours Truly

Struggling with supply chain vulnerabilities or need tailored solutions for your unique challenges? I offer consultation services to work directly with your CTO, Principal Architect, or Security Leadership team to:

Assess your systems and identify key risks.
Recommend actionable, budget-friendly steps for mitigation and prevention.

With years of expertise in cybersecurity and compliance, I can help streamline your approach to supply chain security without breaking the bank. Let’s collaborate to make your operations secure and resilient.

Schedule Your Free Consultation Today

Building a Resilient Supply Chain

The UK’s National Cyber Security Centre (NCSC) principles for supply chain security provide a pragmatic roadmap for businesses. Here’s how to act:

Understand and Map Dependencies
Organizations should create a detailed map of all dependencies, including direct vendors and downstream providers, to identify potential weak links.
Adopt a Zero-Trust Framework
Treat every external connection as untrusted until verified, with continuous monitoring and access restrictions.
Mandate Secure Development Practices
Encourage or require vendors to implement secure coding standards, frequent vulnerability testing, and robust update mechanisms.
Regularly Audit Supply Chains
Establish a routine audit process to assess vendor security posture and adherence to compliance requirements.
Proactive Incident Response Planning
Prepare for the inevitable by maintaining a robust incident response plan that incorporates supply chain risks.

Final Thoughts

The threat of supply chain vulnerabilities is no longer hypothetical—it’s happening now. With reports like CyCognito’s, research into dependency management, and frameworks provided by trusted institutions, businesses have the tools to mitigate risks. However, this requires vigilance, collaboration, and a willingness to rethink traditional approaches to third-party management.

Organisations must act not only to safeguard their operations but also to preserve trust in an increasingly interconnected world.

Is your supply chain ready to withstand the next wave of attacks?

References and Further Reading

What’s your strategy for managing third-party risks? Share your thoughts in the comments!