标签：#owasp

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

Another productive week of Google Summer of Code with OWASP BLT is in the books! Building on the visual blueprints from last week, this week was focused on locking down our structural foundations and diving deeper into the system architecture. Here is a simple breakdown of the progress made and what lies ahead. Milestones The primary goal for this phase was setting up the structural guardrails for how data travels through our app. Finalized Security Contract Structures: Successfully established the foundational security contract structures. This ensures that our application components have a uniform, strict schema to communicate safely and predictably. trying to figureout some missing point on the security_alerts with the help of my mentor. Merge request updates: Glad to share that the initial setup has been done across our repository through these milestones: 🔗 Merge Request #3 🔗 Merge Request #4 🔗 Merge Request #5 🔗 Merge Request #6 🧠 Current Focus: System Design & UI Polish With the basic structures merged, my day-to-day focus has shifted toward high-level engineering and refining the user experience. Architecture & System Designing: Spending time mapping out the data flows to ensure our local-first storage design works seamlessly with minimal, encrypted web updates. Ongoing UI Revamp: Continuing to polish the user interface layouts based on our initial feedback, ensuring the experience feels clean, intuitive, and highly minimal. ⚡ The Next Step: Building the Workers Now that the structural blueprints are active in the project, it is time to make them functional. ⚙️ Contract Workers: Moving forward, the next step is to start creating the edge contract workers. These workers will handle the actual validation and processing logic for the security contracts we just established. The structural groundwork is officially laid, and the architecture is shaping up beautifully. Excited to bring the core backend logic to life next week! 💻🛡️