今日已更新 377 条资讯 | 累计 36392 条内容
关于我们

OWASP A03 & A04: Understanding Software Supply Chain and Cryptographic Failures

SAMYUKTHA SARAVANAN 2026年08月27日 14:30 1 次阅读 来源:Dev.to

By Samyuktha Introduction Some categories in the OWASP Top 10 are about what's broken in your own code. A03 and A04 are about something a little different — whether you can trust what your application depends on, and whether sensitive data is actually protected wherever it lives or travels. This post covers what I learned about both categories, and how I applied that thinking to an authorized web application afterward. The result wasn't a dramatic one, and part of it wasn't even fully testable. Both of those turned out to be useful lessons in their own right. Scope : This post covers concepts I studied around A03 and A04, plus a hands-on look at the client-side resources, storage, and login/dashboard flow of an authorized application. No destructive testing was performed, and identifying details about the target have been omitted. I'll refer to it simply as the assessed application. Phase 1: A03 — Software Supply Chain Failures This category covers what happens when an application depends on components that are compromised, vulnerable, outdated, unverified, or poorly managed — libraries, packages, SDKs, APIs, models, even the CI/CD pipeline that builds and ships everything. A few concepts stood out: Third-party risk isn't your code, but it's still your problem — a vulnerability doesn't have to originate in your own codebase to affect your application. It can arrive through a dependency you imported once and never revisited. Build pipeline integrity — an insecure or poorly monitored CI/CD process can be just as dangerous as a vulnerable library, since it controls what actually reaches production. Provenance matters — knowing where a component came from, and whether it's been tampered with, is as important as knowing what it does. Continuous tracking, not one-time review — dependencies need to be monitored and patched on an ongoing basis, not just checked once at integration time. The SolarWinds incident is the go-to example here — attackers compromised a build system

本文内容来源于互联网,版权归原作者所有
查看原文