Operations | Monitoring | ITSM | DevOps | Cloud

MIT and Apache 2.0 are the easy licenses. Generally, they let you do what you want. Copyleft licenses are the ones that come back to ask questions later, especially once you're generating revenue off the component. This video covers why license compliance gets challenging, and what actually keeps it under control: The goal isn't avoiding open source. It's knowing what's actually in there before a license or a vulnerability surprises you.

There's a common assumption that the EU Cyber Resilience Act is a hardware and IoT manufacturer concern. Actually, it affects any SaaS company selling into the EU too, and that's a gap in awareness worth closing. This video covers what the CRA is actually there to do and what it means for your own software supply chain: Securing your customers' supply chain starts with being able to account for your own.

You don't need a complete compliance program on day one to make real progress on CRA. You need to close the most visible gaps first. This video covers where to start: None of this is CRA-specific busywork. It's the same foundation most mid-sized software companies need regardless of the framework.

Open up an AI model and what's actually inside is a floating array of decimal points. No one can look at that and confirm it hasn't been tampered with, doesn't contain bias, or wasn't trained on poisoned data. This video covers why that changes how you need to think about trusting a model: If you can't unpick the model itself, you have to be able to trust its origin.

Sometimes there's a vulnerability in a package you can't remove. Legacy dependencies don't always come with an easy fix. The one thing you don't do is bury it in the backlog with no dates and no reasoning attached. This video covers what a defensible response actually looks like: Your ability to show your work on unfixed vulnerabilities is more important than simply identifying them.

If an AI model can find a vulnerability for an attacker, the same model should help a defender fix it. In practice, the math doesn't favor the defender. This quick video digs into the real asymmetry AI-powered vulnerability discovery creates: The goal is models acting as tools for defenders, not weapons for attackers. Getting there means rethinking how much ground your team can realistically cover on its own.

npm and Python get all the security attention, but attackers don't limit themselves to your highest-volume formats. A Docker image, a Helm chart, or a Rust crate can all be an entry point. If your security policy is built around the formats you use most, the formats you've deprioritized become the blind spot. This video breaks down why artifact management needs to be centralized across every package format, not just the popular ones.

There's a risk window after a malicious package is published when nobody knows it's there. Scanners alone can't close that window.

Every dependency security program needs a way to handle packages that have a valid business reason to stay in use despite a CVE or license issue. Ideal exception processes give developers full context upfront, including safer alternatives, then route real requests to a security team that weighs the risk profile and logs who requested it, who approved it, and for how long. Get the friction wrong in either direction and the process fails: too much and developers route around it, too little and it becomes the default path.

Open source is the backbone of most software. But should developers trust OSS? npm, PyPI, and Maven don't vet packages before publication, so "publicly available" doesn't automatically mean "safe to pull right now." A secure OSS posture is to trust the ecosystem but verify at ingestion: route packages and dependencies through a controlled layer that runs scanning, age checks, and malware detection before anything reaches a build.