NIST Issues SSDFv1.2 with Runtime-Security Focus

Using the National Institute of Standards and Technology (NIST) #SSDF helps organizations to meet the following #SecureSoftwareDevelopment recommendations: 1. Organizations should ensure that their people, processes, and technology are prepared to perform secure software development. 2. Organizations should protect all components of their software from tampering and unauthorized access. 3. Organizations should produce well-secured software with minimal security vulnerabilities in its releases. 4. Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.  #SSDLC #ApplicationSecurity #AppSec

Having worked on vulnerability management over a decade ago, it’s nice to finally see guidance focused on making patching a more integral part of the secure development lifecycle and not a compliance task.

If you’re tracking NIST #SSDF, NIST just published the initial public draft of SP 800-218r1 (SSDF v1.2), and Amit Katz did a great job distilling the key changes into practical next steps. Learn what’s coming around continuous improvement, more resilient software updates, and stronger expectations for validating real-world configurations. These updates push teams toward repeatable, provable security practices (not one-off checklists). And it’s exactly where Cycode customers are already strong, with the visibility and evidence to show what’s working across the SDLC. Worth a read: https://lnkd.in/d7Z_KZ8u

The OWASP® Foundation Top 10 for Agentic Applications (2026) signals a quiet but important shift in how software security risk is being understood. Not around models. Not around infrastructure. But around behavior. What the framework surfaces is a structural visibility gap in modern security stacks: • limited visibility into developer and autonomous agent actions • across tools, identities, memory, delegation, and execution • before traditional security controls engage When read holistically, a clear pattern emerges: • the most consequential failures start upstream • before code is deployed • before infrastructure is provisioned • before runtime enforcement is possible This is not a failure of existing security controls. It reflects how software systems have evolved toward autonomous execution. From this perspective, Developer Security Posture Management (DevSPM) emerges as an architectural response to that gap. DevSPM focuses on observing and contextualizing developer and AI-agent actions early—serving as an upstream behavioral control plane that complements downstream security enforcement rather than replacing it. Get more insights in our recent blog post: https://lnkd.in/d9bXHdu4

🔄 𝐅𝐫𝐨𝐦 𝐒𝐞𝐜𝐮𝐫𝐞 𝐂𝐨𝐝𝐞 𝐭𝐨 𝐒𝐞𝐜𝐮𝐫𝐞 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲: 𝐓𝐡𝐞 𝐄𝐯𝐨𝐥𝐮𝐭𝐢𝐨𝐧 𝐨𝐟 𝐒𝐒𝐃𝐅 𝐯1.2 📢 NIST has released the 𝘐𝘯𝘪𝘵𝘪𝘢𝘭 𝘗𝘶𝘣𝘭𝘪𝘤 𝘋𝘳𝘢𝘧𝘵 of 𝘚𝘗 800-218 𝘙𝘦𝘷. 1, introducing SSDF Version 1.2 as a meaningful step forward in how we approach secure software development. This update goes beyond secure coding and emphasizes 𝘰𝘱𝘦𝘳𝘢𝘵𝘪𝘯𝘨, 𝘶𝘱𝘥𝘢𝘵𝘪𝘯𝘨, and 𝘤𝘰𝘯𝘵𝘪𝘯𝘶𝘰𝘶𝘴𝘭𝘺 𝘪𝘮𝘱𝘳𝘰𝘷𝘪𝘯𝘨 software systems in real-world environments. The draft is also open for public comment through January 30, 2026, making this a timely moment for practitioners to help shape the final guidance. 🔐 Version 1.2 refines SSDF into an outcome-driven, SDLC-agnostic framework designed for modern delivery models, including cloud-native architectures and shared responsibility environments. It’s not just about implementing controls; it’s about strengthening the system through continuous learning and resilient engineering. The addition of 𝘗𝘖.6 (𝘊𝘰𝘯𝘵𝘪𝘯𝘶𝘰𝘶𝘴 𝘗𝘳𝘰𝘤𝘦𝘴𝘴 𝘐𝘮𝘱𝘳𝘰𝘷𝘦𝘮𝘦𝘯𝘵) reinforces the need to evolve practices as threats change, while 𝘗𝘚.4 (𝘙𝘰𝘣𝘶𝘴𝘵, 𝘙𝘦𝘭𝘪𝘢𝘣𝘭𝘦 𝘚𝘰𝘧𝘵𝘸𝘢𝘳𝘦 𝘜𝘱𝘥𝘢𝘵𝘦𝘴) elevates update safety by emphasizing phased rollouts, rollback readiness, and update integrity. These are not abstract ideals; they are practical disciplines security-conscious organizations must intentionally design into their delivery pipelines. ⚙️ SSDF v1.2 highlights a shift from point-in-time compliance to continuous validation and operational resilience. Too many programs still treat secure development as static policy, even though real risk often emerges later through brittle release processes, patching friction, and software supply chain complexity. Strong implementations translate continuous improvement into measurable cycles, safer-by-default deployment patterns, and controls that remain effective under real delivery pressure. 𝐓𝐞𝐚𝐦𝐬 𝐭𝐡𝐚𝐭 𝐭𝐫𝐞𝐚𝐭 𝐒𝐒𝐃𝐅 𝐯1.2 𝐚𝐬 𝐚 𝐬𝐭𝐫𝐚𝐭𝐞𝐠𝐢𝐜 𝐜𝐚𝐩𝐚𝐛𝐢𝐥𝐢𝐭𝐲, 𝐧𝐨𝐭 𝐚 𝐜𝐨𝐦𝐩𝐥𝐢𝐚𝐧𝐜𝐞 𝐜𝐡𝐞𝐜𝐤𝐛𝐨𝐱, 𝐰𝐢𝐥𝐥 𝐛𝐞 𝐛𝐞𝐭𝐭𝐞𝐫 𝐩𝐨𝐬𝐢𝐭𝐢𝐨𝐧𝐞𝐝 𝐭𝐨 𝐬𝐡𝐢𝐩 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐭𝐡𝐚𝐭 𝐬𝐭𝐚𝐲𝐬 𝐬𝐞𝐜𝐮𝐫𝐞 𝐚𝐟𝐭𝐞𝐫 𝐢𝐭 𝐬𝐡𝐢𝐩𝐬. 💬 How is your team approaching continuous improvement in secure development? What has been the hardest part of delivering secure updates without disruption? #softwaresupplychain #securesoftwaredevelopment #zerotrustarchitecture #cybersecurity #cyberriskmanagement

Authorization is easy… until you actually have to scale it. 🔐 Most teams start with simple RBAC (Role-Based Access Control). It’s clean, it’s intuitive, and it works—until your 5 roles turn into 500, and nobody knows who actually has access to what. This is the "Role Explosion" trap. If you’re building for modern security (Zero Trust) or complex compliance, you might need to move toward ABAC (Attribute-Based Access Control). It’s powerful, but are you ready for the implementation complexity? I’ve put together a quick cheat sheet on the 4 most common Authorization strategies we use today: 🔹 RBAC: The gold standard for internal teams. Simple, but watch out for role bloat. 🔹 ABAC: The future of granularity. Uses "Context" (Time, Location, Device) to decide access. 🔹 OAuth 2.0: Not just for "Login with Google." It’s the backbone of modern API security. 🔹 ACL: Old school? Maybe. But for file-level permissions, it’s still incredibly effective. The big question for the architects here: I personally find ABAC the most resilient, but the "Policy Engine" overhead can be a nightmare to maintain. On the other hand, RBAC almost always becomes a mess after the first year of scaling. 👇 Which one are you using in your current project? Or are you running a "Hybrid" approach? Let’s discuss in the comments! 📌 Found this useful? Save it for your next System Design interview or Architectural review! #SystemDesign #CyberSecurity #SoftwareArchitecture #IAM #Coding #TechCommunity #CloudSecurity #Programming #WebDev #MeghashyamV

If your application security mitigation strategy starts at the code and not at the edge, you’re already behind. That edge is where F5 ASM operates as part of the application, not in front of it. Modern applications are multi-tier and multi-team by design. A single vulnerability can touch interfaces, logic, shared libraries, vendor code and platform config, which means multiple teams, coordinated testing, and long lead times. There are two main causes of modern security incidents: CVEs and Development issues. CVE > Shared frameworks, libraries, and platforms. One CVE can hit many apps and tiers across many teams. Deploying new Vendor Libraries means finding every affected service, coordinating owners, testing across tiers, then waiting for change windows and deployments. That can take days or weeks/months. Developer mistakes > Not incompetence but normal realities: missing validation, unsafe assumptions, untested edge cases. Fixing these properly still requires code changes, review, retesting, and a safe release. So either way, the app or apps have known, likely public issues that are not immediately mitigated. 🛡️F5 ASM can mitigate risk immediately using: • Standard and custom signatures • Entity-based configurations aligned to how the application actually behaves • Advanced F5 ASM/WAF mitigations This allows same-day risk reduction, while teams work toward the correct long-term fix. Mitigations can be staged, monitored, and reported, something rarely possible with application-level fixes, which increases testing time and delays. THE F5 TMOS is the outer tier of the application. See it that way, and the boundaries and responsibilities finally make sense. Fix the Core app code, but don’t leave the front door open while you wait 3 months for a code release. 👣 Follow me for real-world F5 ASM insights and training from real-world and global, business-critical deployments. -

Unpopular opinion: If security is a 'department' in your company rather than a 'habit' in your IDE, you’ve already lost the battle. 🛑 We love talking about 'Shift Left' security, but let’s be real—for most teams, it’s just a fancy slide in a corporate deck. We treat security like a final exam we hope to pass at the end of the semester, instead of treating it like the actual work. For the junior engineers out there: think of security like your code style or variable naming. You don't write a thousand lines of messy code and then 'fix' the style at the very end. You do it as you go because it's part of writing good software. Security is exactly the same. It’s not an extra feature; it’s a quality requirement. 📝 As you move into senior roles, this gets even more critical. 'Treating security like code' isn't just a catchy phrase. It means: 🔹 Ownership: If you wrote the logic, you own the vulnerability. No more throwing it over the fence to the 'Security Team' to find. 🔹 Integration: Security checks should live in your CI/CD pipeline. If a scan fails, the build fails. No exceptions. We don't ship broken code, so why would we ship insecure code? 🏗️ 🔹 Continuity: A quarterly audit is basically useless in a world of daily deployments. If you aren't scanning every single PR, you aren't actually secure. I’ve seen too many 'emergency patches' that could have been a simple 2-minute fix during development. The logic is simple: if it’s not in the repo, it doesn’t exist. If it’s not automated, it won’t happen. 🛠️ We need to stop the 'us vs. them' mentality between developers and security auditors. If you're building the product, you're the first line of defense. Do you think developers are being overloaded with too much 'ownership,' or is this just the reality of modern engineering? Let’s talk in the comments. 👇

𝗢𝗻𝗲 𝗽𝗼𝗹𝗶𝗰𝘆. 𝟱𝟬𝟬𝟬 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀. 𝟭𝟬𝟬% 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲. That's the result I helped a customer achieve last quarter. Their challenge? Security scanning was configured per-project using CI templates. Adoption was all over the place — some teams included them, others forgot, a few opted out entirely. The security team was exhausted, chasing developers to update their .gitlab-ci.yml files. I introduced them to 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗣𝗼𝗹𝗶𝗰𝗶𝗲𝘀. 🔐 𝗛𝗲𝗿𝗲'𝘀 𝗵𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀: Define your security jobs once at the group level. They automatically inject into every pipeline — no template includes, no developer action, no exceptions. The policy lives in a dedicated security project. Security owns it. Devs focus on shipping. 𝗢𝗻𝗲 𝗺𝗲𝗿𝗴𝗲 𝗿𝗲𝗾𝘂𝗲𝘀𝘁 → 𝗶𝗻𝘀𝘁𝗮𝗻𝘁, 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝘁 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲 𝗮𝗰𝗿𝗼𝘀𝘀 𝘁𝗵𝗲 𝗲𝗻𝘁𝗶𝗿𝗲 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻. What made this approach click: → 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗲𝗻𝗳𝗼𝗿𝗰𝗲𝗺𝗲𝗻𝘁 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗳𝗿𝗶𝗰𝘁𝗶𝗼𝗻 → 𝗭𝗲𝗿𝗼 𝗰𝗼𝗴𝗻𝗶𝘁𝗶𝘃𝗲 𝗹𝗼𝗮𝗱 𝗼𝗻 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 → 𝗜𝗻𝘀𝘁𝗮𝗻𝘁 𝗿𝗼𝗹𝗹𝗼𝘂𝘁 𝗼𝗳 𝗽𝗼𝗹𝗶𝗰𝘆 𝘂𝗽𝗱𝗮𝘁𝗲𝘀 → 𝗖𝗼𝗺𝗽𝗹𝗲𝘁𝗲 𝗮𝘂𝗱𝗶𝘁 𝘁𝗿𝗮𝗶𝗹 𝗳𝗼𝗿 𝗰𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝗰𝗲 The best part? The security team's role shifted. They went from "the people who block our MRs" to "𝘁𝗵𝗲 𝗽𝗲𝗼𝗽𝗹𝗲 𝘄𝗵𝗼 𝗺𝗮𝗸𝗲 𝗼𝘂𝗿 𝗰𝗼𝗱𝗲 𝘀𝗮𝗳𝗲𝗿 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝘀𝗹𝗼𝘄𝗶𝗻𝗴 𝘂𝘀 𝗱𝗼𝘄𝗻." That shift in perception? That's when security culture actually takes root. Have you tried Pipeline Execution Policies? I'm curious how you've structured yours.

The current 'shift-left' security approach often creates unmanageable noise and toil for developers, leading to security fatigue rather than improved posture. Large, generic base images, while initially convenient, lead to increased attack surface, more vulnerabilities, and significant security and operational drag over time. Adopting secure, purpose-built foundations like hardened container images can reduce complexity, improve developer experience, and offer performance benefits. When secure foundations are the default, security hardening and supply chain hygiene are managed centrally by experts, reducing interruptions and freeing developers for product work. Effective software security scales by leveraging strong defaults and secure foundations, not by forcing developers to constantly address security issues at the application layer. https://lnkd.in/gy7TFnnu