Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Filling in some blanks on large scale policy testing with Gusto‘s Nicholaos Mouzourakis.

Rego, the policy language of the Open Policy Agent (OPA), is known for its flexibility and power in policy enforcement across various systems. Its declarative syntax and data-centric approach make it versatile for application authorization, infrastructure as code (IaC) authorization, and network policies. To fully appreciate OPA/Rego’s capabilities, it’s helpful to compare it with other policy languages and frameworks like AWS’s Cedar and Google’s Zanzibar.

The huge ecosystem of integrations has over time become a true differentiator for Open Policy Agent (OPA), and an embodiment of the project’s promise to provide policy across the “whole cloud native stack”. Integrating OPA into a new tech stack also tends to be a rewarding experience for developers, which might help explain why so many integrations have been provided by external contributors over the years.

Among other things, the OWASP organization delivers reports on the Top 10 most prevalent and important security risks for web-based software development. In 2019 they started reporting on the Top 10 API Security risks and refreshed that list in 2023. In this blog we describe how OPA/Styra can help with 9 of the 10 risks, and for each one we rate how impactful OPA/Styra is: Below we detail each of these 10 risks and briefly how to address them with OPA and Styra.

Relationship-based Access Control (ReBAC) is a common requirement when applying Policy as Code controls in modern applications. Consider sharing a document with a collaborator in a different organization. As the collaborator is in another organization, it might be hard to grant them a pre-defined internal role without granting more permissions than needed – if indeed an external identity can be bound to an internal role at all. This is where ReBAC comes in.

The microservices architecture is a software development strategy in which applications are broken down into smaller components called microservices. Each microservice is responsible for a specific task or business function and communicates with other microservices through application programming interfaces (APIs). Effectively managing a microservices application requires monitoring, much like any other IT infrastructure.