Disruption #1: Code to Cloud DSPM

Two weeks ago, I met the CEO of Privya, an innovative Israeli startup. Their latest product initiates with a traditional AppSec workflow: an agentless approach that connects to GitHub or your preferred code repository. And then, voilà—the privacy scan begins. But you might wonder, what kind of scan? It’s not SAST, nor is it SCA. Here’s how Privya describes it:

"Privya automatically builds a relationship map between all services, storage systems, and applications. It identifies third parties where data is shared and documents which personal and sensitive data are used where and how data flows between the various elements. This process happens much more quickly, comprehensively, and accurately than any manual mapping process and is continuously updated when triggered by the CI/CD."

So, it's a privacy solution that feels like AppSec, flows like AppSec, and even smells like AppSec! How so? The privacy scan focuses solely on code, yet it can identify both structured and unstructured data sources used by the application. Additionally, it maps all third-party services that the app connects to. In other words, it can discover the main data flows and potential data leakage vectors.

The question that comes to mind is, “How much privacy data can a code scan actually identify?” Privya claims that their ML-driven scan can achieve semantic classification by analyzing variables and function calls, identifying the use of personal information (PII). For instance, the code might run a Snowflake query using variables like user_name and cc. Later in the flow, the code might show that this data is shared with Salesforce via an API call, which would be flagged as a privacy risk. Findings can then be prioritized based on severity and confidence.

You get the idea: it’s not a complex data scan of all your data clouds ala DSPM, but one scan may also lead to the other. Eventually the left meets the right. The discovery of a specific data source in the code can trigger a targeted data scan of the tables and columns referenced in the code to precisely classify the data involved in the flow. The need for regular compliance scans of data repositories does not disappear. One can even foresee an ASPM approach where DAG scan results can be ingested and correlated with the privacy code scan to get a more complete picture across code and infrastructure.

From a remediation standpoint, there is a significant advantage in integrating with the application code and working directly with developers. Establishing a graph of application-to-data flow from the left provides indisputable value, as scanning code for privacy risks can reveal critical insights. This approach helps identify potential issues early in the development process, enabling more effective remediation. Who knew there could be so much value in scanning code for privacy risks? Brilliant: from code to cloud DSPM!