Want developers to take care of security? Make it easier for them!
Application security is a major concern these days, with organizations like OWASP highlighting how bad things actually are. At the same time, application development practices have also changed significantly with the rise of the “Shift Left” approach, which pushes security considerations earlier in the process.
The challenge of Shift-Left
Now, don’t get me wrong—”Shift-Left” is great. Integrating security early in the software development process is a good, proactive mindset that prevents problems rather than dealing with them after they occur.
The thing is, most security vulnerabilities are being found in the code, and that’s where DevSec and DevSecOps come in.
The rise of DevSec
With the rise of DevSec and DevSecOps, developers are now expected to take an active role in security, using various tools and taking 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, as I mentioned, is in the hands of the developers, and it’s them who need to find a way to balance feature development with maintaining a strong security posture.
So, how can we help developers? What can help them focus on app development, maintain security best practices, and have a good time overall? The answer, I believe, lies in improving the Developer Experience (DevEx).
By making security tasks more intuitive and naturally integrated into the development workflow, developers can handle security effectively without disrupting their application development workflow. Let’s take a look at how:
The solution: Developer Experience (DevEx)
Improving Developer Experience (DevEx) is the key to helping developers manage security. We discovered this through our work with authorization. With applications’ ever-growing complexity and microservice-based architectures’ growing popularity, permissions have become a major security concern in recent years, with developers expected to handle models like RBAC, ABAC, and ReBAC.
The problem with these requirements is that they often don’t fit into the typical development workflow, making authorization an extremely difficult challenge to tackle.
Our approach at Permit was to focus on simplifying these tasks from the application development side rather than just the security side. Instead of asking developers to start from scratch or learn complex security models, policy engines, and policy languages (Those who have dealt with OPA’s Rego know how complex it can get at first), we aimed to provide capabilities that developers can integrate into their existing workflows.
Offering a no-code UI for creating and managing authorization policies, and APIs that use familiar concepts like entities, resources, and data structures, for example, made it easier for developers to integrate security into their applications without becoming security experts.
They, of course, still need to understand how to utilize the system in the best way – but they can do so without developing intricate systems from scratch and without writing policy code – unless they really want to.
We chose to frame complex security concepts in terms that align with the development process, such as user and resource segmentation, which can be achieved based on conditions. Thus, instead of talking about ABAC, ReBAC, and Relationships, we make it intuitive for developers to configure security settings that match how their products work.
It has been our experience that making this accessible to developers makes it much easier for them to incorporate it into their application development workflow. Today, even though our product is based on concepts quite complex for the average software developer (We mentioned policy engines, policy-as-code, etc.), most of our users find it enough to work with our SDKs and no-code UI.
This approach makes security a natural part of application development.
In the end, by speaking the language of developers and simplifying security tasks, we help them focus on what they do best: building great applications. This results in a more enjoyable development process and, more importantly, better application security.
Not just developers
A good user experience in security doesn’t stop with developers; it extends to other stakeholders, including end users.
Who uses our application and the level of control they expect to have is a major factor to consider. Aside from end users, we’ve got dozens of stakeholders, including internal non-technical members of our organization, DevOps, RevOps, AppSec teams, developers, and, don’t forget, AI agents and non-human users.
These users each require their own level of access to the application; they need a way to safely delegate permissions and permission management, and these require good experiences. Why?
Poor user experience is one of the biggest vulnerabilities in security.
Bad user experience has a strong tendency to encourage users to make “shortcuts” – bypassing difficult-to-use security features. (For Example, Giving everyone Super-Admin because configuring actual roles takes too much effort) This compromises security.
By focusing on both developer and user experiences, we aim to cover the entire security circle, considering the needs of all stakeholders involved in using the application.
Embeddable Access Control components
An example of this is our “Access Requests” and “Approval Flows” embeddable components. We realized that developers needed more than just tools to model, configure, or audit security settings—they needed ways to give users a clear and manageable experience of controlling their data and actions within secure boundaries.
By offering these components, we provide users with an easy way to handle access control, ensuring data stays secure without needing to navigate complex security configurations. This approach helps prevent security shortcuts and enhances overall security by making it accessible and understandable to everyone involved.
Industry example: ArcJet’s DevEx approach
We’ve boasted our own methods enough – but we are not the only ones with this approach. ArcJet, for example, has adopted a developer-friendly model that embeds security into the development process very naturally. Instead of treating security as a separate layer that developers must manage, ArcJet provides an SDK that developers can integrate directly into their applications.
ArcJet’s bot detection tool, for example, doesn’t require developers to configure complex network security settings. Instead, it offers an SDK that can be used within the application development process. This allows developers to model better bot protection based on their specific use cases, making the security integration feel natural and straightforward.
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.
A wholistic approach to DevEx
Security is undeniably crucial, and we need experts to lead the charge in security work and terminology. However, from our experience, it’s 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).
At the same time, we produce content that dives deep into security concepts like RBAC, ABAC, and ReBAC. By constantly engaging with the Identity and Access Management (IAM) community, we aim to bridge the gap between complex security ideas and practical developer tools.
A holistic view of DevEx encompasses the entire application development process, from initial SDK integration to CI/CD workflows and production. This is why 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 seamless and efficient from the first developer building a POC to the final CI/CD implementation.
Enjoying the process
Enhancing DevEx is a powerful way to improve application security. By making security tasks easier and more integrated into the development process, we can help developers create secure, high-quality applications while enjoying the process.