Hello there! Daniel here with another digest 💌
This week, we talk about Developer Experience.
(And making it better) (But not for you, but for security’s sake)
We all know that "Shift Left" is a big thing. And it’s a great thing as well, as it pushes security considerations earlier in the software development process. That’s a good, proactive mindset that prevents problems rather than dealing with them after they occur.
The thing is, with the rise of DevSec and DevSecOps, developers are now expected to take a much more active role in security, use various security tools and take responsibility for it. While that might sound promising, the facts are simple: Security is extremely hard, and nobody really likes doing it.
The responsibility, though, is now in the hands of the developers, and they need to find a way to balance feature development with maintaining a strong security posture.
So what can we do about it? What can help developers focus on app development while maintaining security best practices? Well, glad you asked.
I believe the answer lies in improving Developer Experience (DevEx): By making security tasks more intuitive and naturally integrated into the development workflow, developers can handle them more effectively and without disruptions. Let’s take a look at how:
Case Study: Fine-Grained Authorization
Authentication is basically a non-problem at this point. The vast majority of application developers just use authentication services that provide straightforward code they can integrate into their applications.
You get an SDK, which gives you a user object, based on which you can make the decision of allowed/denied. In authorization, though, the same kind of "if" statement that can be used to make an allow/deny decision is much harder to make.
But the fact that it’s harder doesn't mean it’s unsolvable without building the whole thing yourself from scratch.
Authorization is a tricky space. Applications are getting more complete and distributed, permissions are a major security concern, and standard models like Access Control Lists or even basic Role-Based Access Control are no longer enough for basically any application these days.
This means developers are expected to develop pretty intricate authorization systems, uphold the latest security best practices, know what policy engines are, and learn new languages like OPA’s Rego in which authorization policies are written.
You know what they’re not doing while they’re dealing with all of that mess?
Building the actual cool, unique features of the application that they are building. That’s what.
The Solution? Better DevEx:
Our approach at Permit was to simplify these tasks for application developers and help integrate them into their workflows. We did so by offering a no-code UI for creating and managing authorization policies, and APIs that use familiar concepts like entities, resources, and data structures. This made it easier for developers to integrate security into their applications without pivoting their careers into security development.
At the end of the day, as intricate as authorization can get - it’s a pretty basic requirement in every application these days. A policy like: “Only a person with this role in my app can edit this group of resources during work hours - oh, and also, I need to have an interface for my users to request access to other resources” can’t mean a role pivot for an entire team of application developers.
To avoid that, we chose to frame complex security concepts in terms that align with the development process (Like talking in terms such as “user and resource segmentation”, which can be achieved based on conditions, instead of talking about ABAC, ReBAC, and Relationships).
We also try to give as many of these capabilities as possible with a no-code UI and easy-to-use SDKs. These functionalities are not unique to any product—there’s really no point in building them from scratch. They should feel like a natural part of application development.
At the end of the day, we’re just trying to help developers focus on what they (supposedly) do best: building great applications.
It’s Not Just About Developers
I already talked about considering who the users of your application are in one of our previous issues. I won’t repeat myself too much, but the question of who uses our application and the level of control they expect is a question we must have an answer to.
Apps today are accessed by dozens of stakeholders: DevOps, RevOps, AppSec teams, developers, God forbid - non-technical members of our organization, and, on top of it all - AI agents and non-human users. All of these require their own level of access to the application and a way to safely delegate permissions and permission management.
What does this mean? You guessed it - These people (And bots) need good user experiences.
Why? Because bad user experience is one of the biggest vulnerabilities in security.
Just think for a second about every time you’ve granted, or been granted, a “Super-Admin” role even though you really didn’t require full unrestricted access to the entire application. You got it to just make some tiny change somewhere, and you got it because someone was lazy.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F754b51ef-bfbc-4c4d-bb30-96a3ea4d5ef2_1600x1600.png)
Well, not exactly lazy - they were given a bad user experience, which made making this tiny change too cumbersome, which ended with you taking a “shortcut” - bypassing difficult-to-use security features. And that could turn into a serious security vulnerability really quickly.
Again, the solution for this? Focusing on both developer and user experiences to cover the entire security circle, considering the needs of all stakeholders involved in using the application.
We did this with our "Access Requests" and "Approval Flows" embeddable components.
We created these features because we realized developers need more than just tools to model, configure, or audit security settings—they need ways to give users a clear, manageable experience of controlling their data and actions within secure boundaries.
Offering these components allowed us to provide users with an easy way to handle access control, ensuring data stays secure, all without needing to navigate complex security configurations. This, we hope, helps prevent security shortcuts and enhances overall security by making it accessible and understandable to everyone involved.
We’re not the only ones doing this, obviously, so enough boasting.
Look at ArcJet! With their bot detection tool, for example, they don’t require developers to configure complex network security settings. Instead, they offer an SDK that can be used within the application development process, allowing you to model better bot protection based on your specific use case. By simplifying security and making it a part of the everyday development workflow, they help developers build secure applications without needing to become security experts.
Bottom Like - Adopt a Holistic Approach to DevEx
We all know security is crucial. And we believe security experts must lead the charge in security work and terminology. But, that being said, I think it’s really important to distinguish between market education and the actual product we provide.
At Permit we focus on creating a developer-oriented experience with our SDKs, ensuring they integrate smoothly into the Software Development Life Cycle (SDLC) while also producing content (SO much content) into security concepts.
By constantly engaging with our community about Identity and Access Management (IAM), we aim to bridge the gap between complex security ideas and practical tools that developers can use and actually care about.
A holistic view of DevEx encompasses the entire application development process, from initial SDK integration to CI/CD workflows and production. This is why, for example, we support both SDKs and Terraform. Some teams prioritize the product and use SDKs, while others focus on DevOps and CI/CD, modeling with Terraform or other Infrastructure as Code solutions.
A comprehensive approach to DevEx involves considering every step of the development process, ensuring no aspect is overlooked. This ensures that the experience remains efficient from the first developer building a POC to the final CI/CD implementation.
If you’ve gotten so far, I salute you 🫡
Don’t forget to subscribe to this Substack if you haven’t already! ❤️
See you next time,
Daniel