DevSecOps refers to the integration of security controls across the whole software development lifecycle. It is first and foremost an organizational culture, enabled by processes and tools, where development teams share the responsibility for delivering secure software with the security team. This differs from organizations where development and security responsibilities are completely siloed in distinct teams.
It expands on the DevOps model that brought together development and operations teams. The DevOps model didn’t address security problems, so security teams remained separate from the development cycle and often identified security vulnerabilities too late. As a result, DevOps teams began incorporating security testing in the DevOps pipeline. A DevSecOps culture relies on consistent security training for the development team, security champions to spread awareness, and developer-friendly security tools to integrate security directly into the software lifecycle.
Data security is the process of protecting your organization’s data from unwanted actions, such as unauthorized access, data erasure, or theft. The risks of data processing have never been so great for technology companies. The more personal and sensitive data these companies process, the more exposure they have to data breaches and data leaks. Plus, data protection regulations such as GDPR and CCPA puts them at risk of strong financial penalties and bad press.
DevSecOps lacks emphasis on data
Mitigating data risks is the shared responsibility of security and privacy teams. Security teams focus on security risks, such as broken access control and cryptographic failures (see OWASP Top 10 Security Risks), with an emphasis on technical measures. The scope of privacy teams is on compliance risks, like data subject rights or data sharing with third-parties (see OWASP Top 10 Privacy Risks). As they focus on the same asset—data—they are naturally brought to work together. Actually, the security team is often the operational arm of the privacy team when the latter need technical knowledge about the products built by the engineering teams.
You have probably heard about the emerging fields of PrivacyOps, Privacy by Design, or Privacy Engineering. Similar to DevSecOps practices, they refer to the integration of data privacy and data protection into the development lifecycle. In the end, it all comes down to protecting data by mitigating risks—whether they are about security or compliance—as early as possible without impacting software delivery.
The challenge is that data mapping and data security assessments are typically disconnected from the development lifecycle. You require visibility over data flows in your products to assess and mitigate data risks. You need to know when you process new data, which type of data it is (for instance personal, health, or cardholder data), how it is protected, and whether your data security and privacy policies are actually implemented. Yet, data mapping and data risk assessment happens either:
- Before the development process, when writing product specifications. For instance, with a Data Privacy Impact Assessment (DPIA).
- After the development process, once a product is deployed to the production environment. Data discovery and classification tools, like data cataloging software, only connect to your production environment. Data security solutions are not really embedded into DevOps processes.
Let’s take an example: say you are a company processing health data. Your data security policy is to end-to-end encrypt Personal Health Information (PHI). Whenever a developer adds a new column to your database that contains PHI, they must encrypt it. Your risk assessment consists of reviewing new database columns, classifying them into PHI, and if applicable, checking if the data is encrypted.
The problem is that these risk assessments happen after the software releases. Companies look at their databases in their production environment to classify new data and monitor encryption. Weeks can pass between a release and audits identifying the missing encryption. In the meantime, unencrypted sensitive data flows through your systems, which puts your business at great risk if a data breach occurs. Then, mitigating it requires back and forth with your engineering team. It leads to increased risk and operational costs.
Alternatively, you might want to review code changes before your developers ship software. Chances are, your security team is understaffed to handle the pace of engineering teams, and can become a bottleneck for shipping new releases.
That’s precisely the purpose of DevSecOps: to enable engineering teams to keep shipping software fast without compromising on security.
Data security has never been so important, yet the current DevSecOps tools do not allow protecting the smallest and most important asset—data.
Bearer’s “shift left” approach to data security
Data security assessment methodologies normally consist of:
- Identifying data assets (in particular sensitive data), also known data discovery.
- Identifying security and compliance risks.
- Mitigating security and compliance risks.
Bearer’s approach consists of integrating these three steps into DevOps processes using Static Code Analysis (SCA). From writing to deploying, Bearer scans your code repositories in order to:
- Detect and classify data flows between your engineering components (services, databases, third-parties).
- Detect risks according to your data security policies.
- Trigger risk mitigation workflows.
In the above-mentioned example, Bearer automatically detects and classifies new database columns, and detects whether the development team encrypted the data. If they haven’t, we raise a notification for the security team, and trigger a workflow to help the developer encrypt the necessary data. The request can even be blocked before pushing to production. The benefit of Static Code Analysis is that you can introduce data security earlier in the development lifecycle, without actually running the code. It can save you a lot of time and money fixing security issues.
Bearer’s vision is to build a security policy as code engine, embedded into DevSecOps processes, designed for data. Whatever your data security and privacy policies, we aim at helping you implement them without being a bottleneck to developers. Protect data and keep shipping.
4 benefits of bringing data security into development workflows
Shifting data mapping and data security assessment “left” in the development lifecycle helps your organization:
- Reduce risks: Identify and mitigate issues before they are released to production. This improves your overall data security posture.
- Reduce operational costs: Manage risks early in the development lifecycle when they are cheap to deal with.
- Increase developers satisfaction: Provide developers with the timely feedback they need to follow your data security and privacy guidelines. Avoid being a bottleneck and the unnecessary frustration that comes with it.
- Increase revenues: Free up developers’ time for shipping software, and speed up your pace of delivery to meet business goals and KPIs.
Implementing Data Security as Code
Bearer is committed to helping security teams at fast-growing technology companies protect their sensitive information more efficiently. Our data security solution integrates with your Version Control System—GitHub and GitLab—to embed data security practices directly into your development workflows. Regain visibility and control of your data. Curious about how to use Data Security as Code in your organization? Let’s chat!
