Use Your Internal Developer Portal to Drive Better AppSec
Let’s explore how to use internal developer portals to help developers take ownership of AppSec by providing them context and an ability to drive self-service actions with regards to vulnerabilities and misconfigurations.
According to Snyk’s State of Open Source Security report, enterprises employ over nine security tools in parallel, on average. From the developer standpoint, this abundance of tools can create a lot of noise and lead to cognitive load for developers and AppSec teams. That’s not even to mention the specific expertise needed to understand and work with each tool, making it harder for developers to comprehend the context of the tools or what to think or do about what’s inside them.
Platform engineering aims to improve the developer experience by abstracting information for developers and allowing developers to become self-sufficient. In the case of vulnerabilities and misconfigurations, data can be brought from various tools into the software catalog, providing context.
The next stage would be to define scorecards based on vulnerability data, and to offer developer self-service actions through the portal. This way, developers can now address vulnerabilities and misconfigurations with comprehensive, full and specific understanding of the security status of their resources.
How Exactly Do Developer Portals Map to AppSec Tools?
To explain this, let’s first discuss how data is brought into the internal developer portal (IDP).
One of the first questions to be answered when setting up an internal developer portal is the data model in its software catalog. You can represent anything in the software catalog, from microservices, packages, environments, clusters, cloud resources, databases etc.
The choice you make is tied to the targets you’d like to achieve with the internal developer portal and should reflect your goals. You can define these models using templates, by defining a taxonomy or using models such as Backstage’s C4 model.
The next step is extending the catalog to include additional data, from vulnerability data, incident data, feature flags, alerts and more.
A Blueprint-Based Data Model to Extend the IDP With AppSec
In Star Wars, the death star blueprints are what enable Luke Skywalker to wreck the death star. Conversely, in Port, a blueprint functions as a data model that specifies metadata linked to software catalog entities. These form the fundamental components of the portal’s platform, as data is ingested based on blueprint definitions, and the data is presented as catalog entities. This is where you define the data model.
Creating a Vulnerability Blueprint
Let’s look at how to add vulnerability and misconfiguration data into the software catalog.
Ideally we should track misconfigurations together with vulnerabilities, but for this case, let’s try using a simple definition — every vulnerability that developers need to prioritize — and see what we can define in a blueprint.
The blueprint below represents generic vulnerability metadata that can be sourced from varied security tools. What’s great here is that in this one schema you can represent properties coming from all different sources.
And these are the entities that are automatically created based on this blueprint:
In this example, the entities created according to the blueprint schema have varied sources: Snyk, Trivy, Kics, Dependabot, SonarQube, StackHawk, etc. Explore the vulnerability entities in Port’s live demo firsthand by clicking here.
The process of designing blueprints includes setting relationships between them. This lets us understand dependencies along a graph. In Port’s case, you can scroll down in an entity page to find its related entities, such as
- Package versions
- Running services
- Developer environments
- Deployments
Creating Actions and Automations for Your New Entities
Now that Port provides you with a clear and contextual understanding of your vulnerabilities, you can drive automated messages to relevant Slack channels or even open Jira issues and automatically assign them to the correct teams.
This is thanks to the ability to understand from the catalog the source, placement and ownership of a specific workload. Similarly, we can define scorecards based on vulnerability data and define automation when scorecards degrade or have pipelines check vulnerability statuses in the software catalog.
Summary
AppSec teams don’t need to be bottlenecks for developers. Help developers gain autonomy on AppSec by creating a better context for dealing with vulnerabilities and misconfigurations using an internal developer portal. You can even define self-service actions that will trigger resolutions in the AppSec tool.
