A New Emerging Data Security Category: AppSec for Data

We shift data security left. Learn more about why we think it’s the new way to achieve effective data security in your homegrown backend.

By the end of this post, you will see why a new suite of tools is needed to build real data security. Let us start with the beginning - 20 or 30 years ago, businesses had a network (LAN), and everything was happening there; machines and databases connected to each other and resided on-prem. Security was easy (and very naive, too), and there was no SaaS and shadow IT. Everything was within a single perimeter, and a firewall and a VPN were doing a great job. And then came the cloud and disrupted everything.

What Is AppSec?

AppSec (Application Security) is a proactive approach to protecting software applications from threats by addressing potential software vulnerabilities in the code throughout the product lifecycle. It covers a broad range of best practices, technologies, techniques, and processes designed to identify, prevent, and mitigate security risks across software applications.

As a continuous process, AppSec not only enhances security but also contributes to accelerating application lifecycle by minimizing security risks throughout the development lifecycle. For example, by proactively fixing security bugs in the code, rather than finding them being exploited by attackers, already in production, and then going back to fix the code and issue a new patch.

Given the increasingly widespread accessibility of modern applications across the internet and cloud platforms, integrating AppSec into the application development lifecycle is critical. Organizations that prioritize AppSec and embed it in their product lifecycle gain a competitive edge in ensuring the integrity and resilience of their applications.

On Security in Production Environments

With the cloud dominating the software world, we needed more security. The tech stack is vast, with many diverse layers and components, and the task of safeguarding data across all these elements becomes increasingly challenging. And so CSPM (cloud security posture management) was born with Wiz and Orca leading it. CISOs feel safer and in control of their cloud environment. It’s no longer one perimeter anymore, but it doesn’t matter. They really have more control than ever before in the on-prem days. CSPM helps protect everything that is under production, regardless of whether DevOps throws more components into the environment.

Next to them in the production environment for security and vulnerabilities is CNAPP (cloud-native application protection platform), also shifting container security left but helping protect more components as part of the security lifecycle; a whole different approach now, which is really welcome.

One of the most exciting trends that took place in security in the last two years is DSPM (data security posture management), which concentrates on data discovery and categorization of data inside data stores in production environments in our context.

Why is it exciting? Because for the first time, CISOs want to learn more about their data in order to prioritize fixing its protection mechanisms. Fixing can stretch from configuring better credentials, access control policies, and whatever databases let you do with their limited security. For the first time, there’s data visibility and the ability to control and maximize its security posture.

DSPM really helped shape the market. If three years ago CISOs didn’t know what PII was, now they know. PII stands for personally identifiable information, and it’s the data that, when removed from a document, renders it anonymous. It can be unique identifiers like your social security number, national ID, phone number, email address, etc.

DSPM brought more awareness toward data and, specifically, data security. Not to mention that GDPR (general data protection regulation) did the same thing from another angle, from the privacy regulators' interest to protect humans (and their data) using online services.

Yes, there’s also DLP (data loss prevention) that tries to help by detecting malicious activities of smuggling data outside of the organization, but unfortunately, that one is really not useful and feels more against the employees than the threat actors. It is infamous for being hard to deploy and onboard. And I’m not even sure how you deal with it in the cloud. Would you want it on your web app servers?

And besides, my first concern about detection-based technologies (firewalls, WAFs, API security, AV’s, DLP) is what happens if they do not detect the attack. I guess we all know the answer.

Data is tricky; it’s not contained only in data stores. It’s really everywhere, and we will soon touch this nerve.

On Security During Development

At the other end of the spectrum, with one side being Production, we have Development (i.e., software development), which is when developers design their software, gather requirements, and eventually write code. This code has never been faster to be released to production for many reasons:

1. Developers are all about their velocity of iterating and releasing new versions ASAP - think git.
2. Developers now have generative AI like Copilot to help them write even more code.
3. Developers use even more open-source code projects and integrate with them to achieve things faster.
4. Development started to get forked with DevOps, so now they are responsible for so many things about the production environment and gluing it all together, enabling even more velocity.
5. Programming languages that are cloud and velocity-friendly, such as Ruby, Python, Javascript,Typescript, and many new UI frameworks.

Snyk became the darling of open-source security, starting to cover all the CVEs and vulnerable libraries that everybody uses today. Integrating with open-source packages and libraries means that you inherit their security bugs too. Not to mention supply chain attacks, opening a whole plethora of new attacks.

During development, we want to make sure that developers aren’t slowed down and that the opposite happens; they get to run faster and provide the business with new features. And also because writing new code is the most rewarding thing for them. So Snyk was helping with that. But what about the code itself that they write? What about the fact that they need to know security in order to write secure code?

Developers aren’t hackers; they don’t think that way. And when you write code, you always have bugs, and some of them are certain to be security bugs. To the rescue came SAST (static application security testing) or, in other words, code analyzers that would analyze the newly written code and try to audit it to uncover bugs that could become fully exploitable vulnerabilities, leading to the server being compromised (data breaches, ransomware, etc.) or to customer data leaks. Companies like Checkmarx, Veracode, Snyk, and Mend (to name a few) lead this market.

Remember that GenAI and Copilot learned to code by reading all the code in GitHub and beyond. That code is surely written by mostly non-security-savvy developers, and hence it contains vulnerabilities too. In other words, generated code is also vulnerable to many attacks. And it still requires auditing. So, code analyzers aren’t going anywhere; the opposite is true.

Blind Spots and Data Security Problems

And then along came Sally, err Piiano - where we realized that we have blindspots and a few more things that weren’t really addressed until today.

Let’s start with a few assumptions:

1. Developers want to run faster - This is always true because businesses want to grow fast
2. Code should be secure - It’s impossible to prove it’s bugfree, so doing our maximum, hence ‘should’
3. Data must be secure - So many ways to achieve this, but most aren’t good enough
4. Developers run faster than app-sec teams (see the ratio of 1 app-sec engineer to 100 devs)
5. Shifting left stuff proves itself - It worked with open-source projects, containers, and now data. It saves time and money by the ton because you are proactive.

And a few problems we recognized:

1. If data isn’t protected directly, it’s exposed - Data breaches in the headlines are enough or ‘nough said?
2. DSPM is great and needed, but it has blindspots to what developers do with data inside the code. They can store data in other systems and share data with other vendors, and nobody whose job it is to know it would know.
3. In today’s complex production environments, there are so many software components - with vulnerabilities and cybercriminals spraying everything - who knows how they get inside, but eventually, they will hit the data.
4. If developers aren’t going to build security, nobody will - bolting on more layers of defense is good, but they are not truly effective. Again, detection-based tools by nature can miss critical attacks and let an attacker in. This is not good enough anymore.

Compliance isn’t Security

And another problem bugs me -

The next time a business gets attacked, they will start to care. CISOs are going to need to change their strategy soon. Businesses get attacked successfully too much. Doing real security is so hard, but if compliance is what everybody seeks, then we aren’t going to get better. Security compliance is stuck in the 90s, and today, it wreaks more havoc than good because it causes security personnel to neglect the true security that is needed to defend their businesses. The SEC and FCC push businesses to disclose breaches immediately, and it will affect the stock market eventually. And if not that, MGM-style attacks and shutting down systems will start to really get people fired - thus more accountable.

Our Conclusions

All of the above led us to the conclusion that Piiano must shift data protection left to get true data security. There’s no other option. We want developers to build securely. We want them to protect data as they work with it.

We are tired of SQL injections - yes yes, they still occur. We’re tired of compromised encryption keys. And we’re definitely tired of data breaches. Sitting at the code level gives us the best position to protect data - in-context, hence our Vault APIs provide maximum security and really mitigate many attack vectors on data. If you think data proxies can give you the best security, then think again - because transparent pipelines are also transparent to attackers in some ways.

For example, even if you have a proxy to secure a database with better ACLs and security policies, a fully compromised web server will always result in compromised customer data! But that will never happen with a well-designed Vault.

When you find an issue in your data (by using a DSPM tool, for instance) and you want to move it to another place or apply data masking, you will need to change the code. When developers share customer data with a third-party vendor using its APIs, you want to know that it happens because it might violate business contracts, end-user’s consent, or privacy policies. And when developers spill PII in logs, it’s now a whole security incident that you could have avoided in the first place. Or when developers collect and store a new type of data, you would want to make sure it’s covered in terms of privacy (how it can be processed, data retention, etc.) and security (is it stored securely, is it encrypted, who can access it, etc).

AppSec for Data is the Future

At Piiano, we introduce two products to cover application security for data - from visibility to remediation and protection.

Piiano Vault - an advanced secure storage that is designed to mitigate attacks and protect sensitive customer data, be it PII, PHI, PCI, KYC, or whatever confidential data needs to be stored securely in the backend. It’s built for developers as first-class citizens, and it goes beyond security and encryption.

The second product is Piiano Flows - a static code analyzer that tracks sensitive data flows in the code and alerts to policy violations of how the code moves data around, giving a score for codebases so you can get a better posture quickly and guiding you on how to fix things. After all, if data is the new oil, why wait for post-production and attackers to know that we have issues securing it?