Kosli

What’s the point of investing in DevOps, CI/CD, and platform teams if software delivery still crashes into outdated governance processes? If you’re running software delivery in a bank, you'll have thousands of engineers working across a large number of pipelines and applications. With all their gains stuck behind what Mike Long likes to call “The governance wall.” Kosli exists to change that—with software delivery governance that’s automated, provable, and built for scale. Want to learn how other banks are tackling governance at enterprise scale? learn more at https://www.kosli.com/ #EngineeringLeadership #BankingIT #SoftwareDelivery #GRCEngineering

I'm really looking forward to the Open Source in Finance Forum (OSFF) in London later this month... If you could use a discounted ticket, hit me up in the comments!

This. And tooling to collect and evaluate evidence of all of your controls as you go. Pipelines are great for build controls - the checks we put in place as we build our software. But they don’t have long term, or queryable storage. We at Kosli want to help teams in regulated industries deliver with speed and safety. Rather than using it as an excuse uou can make it a competitive advantage.

It's really fun to chat to chat with the folks at RedMonk - an analyst firm that's been tracking the software compliance space since 2004! 🤯

🎯 "We already have a GRC team. Why do we need engineers?" This question kills more GRC Engineering initiatives than budget constraints ever will. The problem isn't explaining WHAT GRC Engineering is. It's demonstrating what it DELIVERS. Your biggest obstacle isn't technical complexity, it's how you position the value-add. When you frame it as "adding developers to compliance," you've lost before you start. When you position it as "getting GRC closer to security while upholding external trust," executives listen. Tomorrow's GRC Engineer newsletter breaks down exactly how to sell GRC Engineering to the 5 stakeholders who can make or break your initiative: ✅ CISO: From "technical debt concerns" to "strategic security visibility" ✅ Head of GRC: From "being replaced" to "amplified expertise" ✅ Finance: From "expensive experiment" to "100% ROI in 12 months" ✅ External Auditors: From "reduced scope" to "deeper conversations" ✅ VP Engineering: From "slower velocity" to "reduced friction" The secret? Address their fears before they voice them. Dropping tomorrow at 9AM EST 📧, make sure you're subscribed! Huge shoutout to Kosli for being the lead sponsor of this week's entry! What's your biggest challenge when pitching GRC Engineering internally? #GRCEngineering #StakeholderManagement #ExecutiveBuyIn

You asked, we delivered. We've introduced read-only roles in Kosli because you made us aware of a trade-off for security-conscious teams: 👉 You either gave users full write access by signing in with SSO 👉 Or you had to block them entirely via your IdP That meant platform teams were often forced to limit Kosli access to trusted individuals — limiting visibility across the organization. But with read-only access you can: ✅ Give everyone the visibility they need 🚫 Without compromising your audit trail 🛡️ And only authorized users can create attestations It’s a small but powerful change — and it’s already live for all customers. https://hubs.li/Q03mV5gr0

🚨 New in Kosli: Read-only access roles 🚨 Kosli admins can now assign read-only roles to users — helping security and compliance teams lock down their SDLC Governance even further. Read-only users can: ✅ View everything 🚫 No creation of attestations or environments 🔐 API access is read-only too Until now, anyone signing in via SSO could create critical resources. With read-only access, only authorized users can attest evidence from your CI/CD pipelines. This new feature has been requested by our Enterprise customers and will give you all more visibility and stronger control. https://hubs.li/Q03mV2V-0

One of the most frustrating tradeoffs in SDLC governance is choosing between giving teams the access they need and protecting the integrity of your audit trail. In Kosli we used to see customers limit access at the platform level—not because they wanted to, but because they had to. Giving someone SSO access meant giving them permission to create attestations. And that’s not something you want to leave wide open. So we fixed it. We’ve introduced a new read-only user role that gives teams full visibility into SDLC activity—without letting them change a thing. A small change, but one that makes your audit trail safer, and your governance more usable. Curious how others are handling access controls in their developer platforms? #DevSecOps #SDLCGovernance #SoftwareDelivery 🔗 https://hubs.li/Q03m9Zz50

I made to to Vegas for ServiceNow’s Knowledge 2025 conference! Amongst all the AI talk, a big theme is understanding change as speed ramps up. HMU 🤙

Trust in software used to be about people. Now, it's about provenance. Can you prove what’s in your code? Where it came from? Who built it and how? We’re pushing on this at Kosli—tracking #SBOMs, linking them to builds and commits, and making that history verifiable. It’s not just for compliance—it’s about trust, clarity, and being able to answer the hard questions before they’re asked. We’re not done yet, but it’s a step toward transparency that scales. 🔗 https://lnkd.in/etxFHcnE #SoftwareGovernance #DevSecOps #SBOM