Debra Farber 0:00
Hello, I am Debra J. Farber. Welcome to The Shifting Privacy Left Podcast, where we talk about embedding privacy by design and default into the engineering function to prevent privacy harms to humans, and to prevent dystopia. Each week we'll bring you unique discussions with global privacy technologists and innovators working at the bleeding edge of privacy research and emerging technologies, standards, business models, and ecosystems.
Debra Farber 0:27
Today, I'm delighted to welcome my next guest, Suchakra Sharma. He's the Chief Scientist at Privado.ai (who's the founding sponsor of this show). Also, I want to disclose that I'm an Advisor to Privado. And Suchakra helps build code analysis tools for data privacy and data security. He completed his PhD in Computer Engineering from Polytechnic Montreal, where he worked on e-BPF technology and hardware-assisted tracing techniques for OS analysis. For the last 6 years Suchakra has been working on enhancing static analysis tooling for fixing security bugs at scale. He has delivered talks and training at venues such as USENIX Enigma, SCALE, The RSA Conference, Blackhat Arsenal, NorthSec, and many others. When not playing with computers, he develops film, photographs, and writes poems. Welcome to Shushakra.
Suchakra Sharma 1:29
Hey, thanks for having me, Debra.
Debra Farber 1:31
Oh, I'm excited to talk with you today. We're going to chat about your background and shifting left for security; and how your...how you applied traditional tested static analysis techniques, such as 'taint tracking' and 'data flow analysis,' for use on large code bases at scale to help fix privacy leaks, you know, right at the source itself. So, I was excited to see that you had worked at an organization for about five and a half years called "Shift Left."
Debra Farber 2:03
First, can you tell us about your background and what interested you in moving from focusing on static code analysis for security in the shift left security space and then moving on to privacy?
Suchakra Sharma 2:15
Yeah, okay. So I've worn many hats during my time. In my early career, I was actually working on infotainment systems you see in cars, and then I moved operating systems and more about performance engineering on code. This was also essentially my research work at Polytechnic Montreal. But, what happened is I had joined Shift Left (and I was one of the founding engineers there), and I got fascinated by the work done in static analysis by my ex colleague, Fabian there. And, I looked at the power of it to find security bugs at scale. and this just blew away my mind. And I believe at that time, this was like a revelation for me; you can say that. So, we're seeing this...that this can also impact just an industry of privacy technology; I decided to explore this area further. And also, in addition, I would say I now align more with the philosophical aspects of privacy, and I wish to work on anything that helps in limiting the erosion of privacy in modern society. What I do now with code analysis and static analysis and doing the shifting left or privacy is actually just a small part of it.
Debra Farber 3:26
Just for our listeners here, could you just untangle the terms 'static code analysis' from 'dynamic code analysis,' just so that it's clear, the distinction?
Suchakra Sharma 3:36
Sure, sure. So static code analysis is the art of analyzing code before it executes. So you have code written, it's not executing, it's just a big blob of text. And then you apply a lot of complex algorithms, and you're able to actually understand what this code would be doing, essentially, when it gets executed. So you know, kind of like having a very early on indication of what is going to happen in the code. Dynamic analysis is actually observing the code as it is getting executed. So, this is also called as 'runtime analysis' in some areas, where the code is now executing at someplace; you pause it; you hook into it; and, you try to understand the behavior of the code at that point. So, that's kind of like the distinction between static and dynamic analysis.
Debra Farber 4:23
Right. And then with dynamic, you also got these security vulnerabilities of the potentially like, inputs that you're collecting as a system, which is slightly different from static code analysis. Right?
Suchakra Sharma 4:34
Yep. Yep. Yep. In very simple terms, I would say that imagine an antivirus software that is running on a system, it is actually doing dynamic analysis - trying to understand during the execution of an application, what might be happening. So, these can be tools. I mean, it could do a lot of other things, but looking at stuff when it's getting executed is essentially dynamic analysis.
Debra Farber 4:55
Awesome. Thank you for that. And so what does the term 'shift left' mean? To you, I know what it means to me. Im sure we aligned. but I'm interested in your journey and perspective.
Suchakra Sharma 5:06
As a computer scientist, I would first say that this, to me looks like a marketing term for static analysis. With like jokes apart, this is more of now larger movement of fixing things early on in the software development lifecycle. I think that's how I view this. So...and also, this is, in fact, the right thing to do in all aspects of software production; the way to fix things very early on ensures that things at...when you execute them, they're not broken because you've already fixed the stuff that could have gone bad before. So, I believe this is the term 'shifting left' and also the movement of shifting left means to me.
Debra Farber 5:47
Awesome. Yeah, I think that makes a lot of sense. I agree with you. It does sound like a marketing term because it is. It doesn't mean that we can't lean into it for the good parts of it; we just want to make sure when people are using the term, they're not 'privacy-washing' their product. And then, I do advise companies, including Privado, and we want to make sure that that branding is part of a movement that's plugged into certain high-level...just shifting left rather than....you know, just another thing to put on a marketing booth that just sounds cool. Like, you know, 'GDPR-compliant' or other things like that. And that's what I mean by privacy-washing; just using the terms of the...and the zeitgeist of the moment to, you know, capitalize on on a brand, trying to get market share. But again, you know, I agree with you that a lot of data scientists - from where they sit - it can definitely sound like just a marketing term when it's actually a movement. So, let's get people on board and build community around that. Right?
Suchakra Sharma 6:45
Yep, absolutely.
Debra Farber 6:47
What lessons have you learned that you could share with us, or insights gleaned from participating in the "shift security left" movement that - I don't know, been going on for like the what, for the past 5, 10 years in terms of like that kind of moniker - that you can apply to the "shift privacy left" movement, to set us up for success.
Suchakra Sharma 7:06
I think one thing that I've learned is that there's shifting security left and getting this mindset that things need to be fixed early on, especially in the security industry has been very concretely helpful. So, you know, it has actually helped a lot of companies and I've seen this first-hand where the bugs that could have actually landed in production are actually stopped very early on. So, thumbs up to everyone who has been doing this. I mean, computer scientist and engineers have been using these tools very early on - even basic tools, like simple linters simple bug detectors that they have been using. But actually, this movement that has happened in the security industry has really changed. You know, it's also a change of mindset that has happened.
Suchakra Sharma 7:55
So now, I believe that privacy also needs to latch on to this. So privacy, right now, is not that engineering-driven, as I have seen between these industries - because now I have seen the stuff before and seeing privacy right now. I believe that it needs to be more engineering-driven. There is a massive opportunity to actually fix privacy bugs at scale again. And, I believe it's the right time that proper tools are available that can help fix these privacy bugs early on - just the way it has been done for security.
Debra Farber 8:29
That makes sense. Okay, so next, I want to ask something that's a little more philosophical of a security question - and that question is what is considered private at a fundamental level? And I just want to preface this with...that very often the term private is used to denote privacy, but that's not really correct; it's really a term around confidentiality, which is a security aim. So, if you could also weave in how privacy is separate from the security aim of confidentiality when discussing your answer, that would be awesome.
Suchakra Sharma 9:03
Hmm, okay. So, I believe that privacy is actually very fundamental to us. And even before humans, and in other species and animals, we have seen this behavior of keeping certain things to themselves - either as just an intrinsic goal to just keep them separate or something that fulfills their needs.
Suchakra Sharma 9:25
So, there's a recent research that had been done where you can see that ravens, they stash the locations of their food that they find. And these stash locations, they keep them very private and they do not share it with other ravens; but they do share it with only their mates. So, this is a pretty interesting behavior. It's kind of like how humans also operate. Same with mating and birth in a lot of animals. So, these these activities are very private, and humans also embraced similar features with them.
Suchakra Sharma 9:58
We have been doing, and other animals also have been doing like early encryption and communication. So, for example, in tribes, we had specific hand gestures and calls during wars and hunts. So, these kinds of things have always been there. So, as societies have advanced, I think this is a time when we require more guarantees of certain privacy, specific things like: health information, monetary information, intimacy communication. These are certain things that are absolutely important for us now to keep private because it's not something that is imposed on us as a society; it is something that is quite intrinsicto us.
Debra Farber 10:37
Yeah, I think that makes a lot of sense. And then, it's almost like the privacy piece comes in when you want certain assurances. And, early on when the societies were, you know...first, we just needed security, right? Like, we just needed to be protected from the bears and like..
Suchakra Sharma 10:56
yep, yeah
Debra Farber 10:57
And then there were...as society starts forming, there's certain additional guarantees that people want, but they do need the trust, and you need to build the transparency, and you need to build...their certain...you know, so I think that the distinction early on from an anthropological point of view, might not track to what we experience today with this explosion of information and data all around us and us focusing on data privacy, but not only wanting to keep stuff sacrosanct by just, you know, wanting to be free from surveillance or prying eyes, or wanting to be, you know...having a space for you to be honest or have your free self. Right? It's about autonomy, too. I think there's just so much there that....
Suchakra Sharma 11:36
Yeah, absolutely, absolutely. So, so certain constructs, like money, were never there before; but, when they were introduced in society, information about how much money someone else has is the leverage that you have on them or they have on you. So again, this this kind of information now suddenly becomes more important to be kept private; or, you know, your transactions to be kept private; or, sometimes be transparent and sometimes be private. So again, you know, the way they are performed, the goal changes of privacy itself.
Debra Farber 12:08
So, transitioning from ancient humans to today, how do we provide guarantees around privacy today in a engineering-focused way, and what do you see as engineers roles in this kind of 'shift privacy left' paradigm?
Suchakra Sharma 12:27
Oh, yes, yes. That's quite important to discuss. So, what has happened these days is that privacy is always seen as a function that customers have to do. Okay, if you open an app, you know, you try to create an account, and it will tell you that, "Hey, you should agree to this...consent to this data being sent," you know, in 10 other places. And, you just hit "Accept," and you're done. Or, you have to scroll through each and every small aspect of what the big 20-page document contains about what's going to happen to your data. So, these kinds of things are just shout towards users and customers.
Suchakra Sharma 13:01
What I believe is that the real people who hold these companies that are building these apps - real people holding them are actually millions of developers and security engineers who build these systems from scratch. They exactly know where the data is going, and how it is produced, and what what is going to happen to that data. So, I think the understanding now is that, because this information already exists with these folks very early on, the goal should also now to bring the responsibility of privacy early on towards the engineering functions, towards the security functions inside organizations. So, even before the data goes into these thousands of databases, the folks who are on these frontline, they know each and every single line of, I suppose, a statement like 'log.INFO/username.' So, they know that this statement is going to generate millions of usernames, which will be spelled in logs and then available when this code is being run. In fact, I discussed this a little bit more in my recent USENIX Enigma talk in Santa Clara as well.
Debra Farber 14:10
Let's discuss the topic of your Enigma talk: "Building an Automated Machine for Discovering Privacy Violations at Scale." You know, I think my listeners will find it interesting as well. So, can you describe for us the tested static analysis techniques that you use to create this automated machine for risk to privacy and code? And specifically, what's 'taint tracking' and how did you do apply 'data flow analysis?'
Suchakra Sharma 14:37
Yeah, so seems like we are like going a little bit more deep into this; so obviously, that's going to be super interesting. So, let's suppose we have a variable in your code, and this variable is called as 'location.' Guess what this variable is going to hold? Obviously, it's going to hold location; you know, developer named it like that. So, this indeed is true that this variable is going to be the creator and the container of location data; we are sure about that. So, now wouldn't it be nice to know very early on where this data is continuing to flow to? So, that's essentially what we use the static analysis techniques to do this early on.
Suchakra Sharma 15:19
So, to do this, what we'll do is we'll first convert the whole source code into a large graph. And why do we do this is because this is essentially how computers understand the code that humans write, you know, in these languages. So next, what we'll do is we'll identify some interesting points on this graph. These points are called as 'sources.' So, they can be variables for now in this graph, in this variable called 'location,' and what we do is we taint them. So think of this taint as leaving like a little red mark on like a box, which is an imaginary box containing this variable. So, you leave this little red mark.
Suchakra Sharma 15:55
And then, we see where all this data contained in this variable is flowing to. So, as an example, if now we have a statement, "X equals location," so then we put this little red mark taint on variable X because now we know that the data contained and location is now going to transmit to X. And we do this again and again, so on, 'til the time...we keep on tracking where this variables data is going. And we do this 'til we reach another interesting point inside this graph called as a sync. So, sync could be a function like log.INFO. So now, if you have been keeping a taint over where the data is going, you will be able to actually tell that, "Yeah, this location variable, it threw these 20 transformations in these 30 files inside your whole source code; it eventually reached this sync like log.INFO. So, following this variable and its assignment through the whole program from source to sink, is achieved this way, by this technique of taint tracking.
Suchakra Sharma 17:00
Now we know about taint tracking. So what is 'data flow analysis?' I think that's another question that you had asked. So...
Debra Farber 17:06
Yes, definitely.
Suchakra Sharma 17:08
So, data flow analysis is actually just this: what you get after taint tracking is essentially what data flow analysis is. So, you get this big graph of lot of information in the code that was there...you know, big complex graph that was there. And now, you have simplified filed it and extracted these little paths from sources to the syncs. And now, we can use this to make some final judgments about the fate of data that goes from the sources and these things. So, that's essentially what data flow analysis is.
Debra Farber 17:40
Awesome. Well, thank you so much for going through that. I think it's really important to kind of understand what we can learn from the security side of the house. Right? It's got 15, 20 years on us over here dealing in privacy.
Suchakra Sharma 17:52
This tooling has been there for a long time with us. You know, we have had this 15-20 years of these deep research on this static code analysis. In fact, it has been there as old as programs have been there. So, this is literally...that's the history of it. And now, it's time to kind of like bring this all in the world of privacy.
Debra Farber 18:14
So, I have multiple questions on that. But the first I'll say is, what does it take to build this type of tooling? Like, is it really giant investment? Is it pretty easy? And, why isn't everyone doing it? Is it easy for enterprise, but hard for small business? Like, what's the state of what it takes to build such tooling?
Suchakra Sharma 18:35
So, I would say that some folks are already building this tooling in-house, you know, all the big organizations. For example, Facebook has a big project called as 'Infer,' which is standard code analysis platform. And then, they also have other projects like 'Pysa.' And another one, I believe, it's called as 'Mariana Trench' for Java analysis. So, these organizations already have this brains and resources, and they are building this tooling, which helps them fix bugs at a large-scale. So, this has already been done in large organizations.
Suchakra Sharma 19:10
For other organizations, there are static tooling that has been developed, or precursors to that, that have been developed. So, for example, GitHub has a very nice team doing code analysis inside their own platforms. And GitLab also has a team like that. So, what I'm saying is that these tools using the same techniques are actually being built in organizations; and they essentially follow similar strategy. The goal is to convert large amount of codes into graphical formats - like different kinds of graphs and trees - and then, you can come up with a system to ask questions to these graphs. So, just like you would ask a question to a friend, "Hey, I wrote this code, and it contains a variable called location. Can you tell me if this variable ever reaches a log?" So this kind of statement, once you find way to ask this question to these big graphs, you could find ways to repeatedly ask these questions. You know, like imagine millions of these questions being asked at scale. And, this is, of course, what you will need to obtain a proper static code analysis system. So, frameworks are there. There are static analysis frameworks already out there, and they can be used to build deeper code exploration tools like this. And yeah, that's essentially what it takes to build such tools.
Debra Farber 20:32
Thanks for that. So, is it like developer-heavy? Like if a company wanted to...didn't have the staff yet and want to go hire someone or a team to do whatever you need to build this, how much capital investment are we talking? If you're like a medium-sized company, you're not necessarily a scaling or, you know, a giant enterprise? Maybe you're scale up?
Suchakra Sharma 20:51
So, I would say that building in-house tooling specifically for static analysis would probably make sense only for very advanced companies, you know, not medium size. I mean, I would say enterprises and those...only those who are specifically dealing with code or development kind of workflow, such as GitHub, GitLab, folks like that, Microsoft, and, you know, variations of these tech companies. I would say, for everyone else, they should probably focus on experienced vendors who have been providing static analysis tooling for a long time, either for security, and now upcoming for privacy. I think that would make the most sense to them. It is a bit tough to hire, you know, a team doing this kind of specific work.
Debra Farber 21:39
Yeah, no, that makes sense. And I know that that's the type of work that Privado helps with. So
Suchakra Sharma 21:43
Yep, yep, yep.
Debra Farber 21:45
Okay, so how can a developer or privacy engineer fix "privacy bugs" in code - and I ask this as the fiancé of a hacker who hacks like HackerOne's platform and you know, Intigriti, and like, you know, it was kind of in that world and like, is in the bug bounty world. So, for a long time, I've been wanting them to start including privacy bugs, and start educating the hackers. But, you know, so I want to better understand this space. So what, how can developers and privacy engineers fix privacy bugs in code?
Suchakra Sharma 22:23
So, I would say that, it's also a way of thinking about the mindset. So, you mentioned hackers. Okay, so hackers have a very different mindset. So their mindset is like, "How can I circumvent something?" - you know, literal thinking about things. The mindset that is required for these tooling is more of a 'auditors mindset,' you know, like very calmly looking at code, understanding how to fix these bugs that are there. Specifically for privacy industry, you know, what we have been doing all this time is scanning databases, network traffic, looking at millions of lines of logs, and searching through secrets that were spilled in those logs and things like that.
Suchakra Sharma 23:07
So this, however, is a new way of looking at code; the way of doing the static analysis for privacy bug fixing is it's a new way of looking at code. So, developers now can carefully think about what is being done to a variable that would be storing the PII data. And when they are auditing the code, the engineers should use tools that tell them very early on what's going to happen. So I think it is a different way of thinking about code.
Suchakra Sharma 23:34
All developers are going to use debuggers. You know, this is a normal way of life, these tools are in your belt when you start coding. So, essentially, fixing privacy bugs should also be thought of like that. You know, you have to really look at the code, not just from the perspective of "Oh, I'll find a buffer overflow here." No, but now this time, look at the code specifically from the perspective that "What if I introduced a new data element to the code? What if I added this variable username?" Now, pause and think about what's going to happen to this username and start tracking it. So, large code bases, you know, auditing the code by looking at the specific data elements and then tracking them either automatically or manually, I think that would be the way to fix privacy bugs.
Debra Farber 24:25
That's awesome. Do you think that there'd be a like a Privacy Bug Bounty Program in the future or are you...
Suchakra Sharma 24:31
I absolutely think so!
Debra Farber 24:33
You absolutely think so. Okay.
Suchakra Sharma 24:35
This is this is going...because look, the fines are coming, and we have seen very recently these large fines that corporations are having. I recently was talking to a customer and they were completely focused on fixing this because they themselves had had a large fine that was handed over to them. So, I believe this is coming. You know, it's not just if it's going to come, but it's about when this arrives. And, I also believe that the biggest challenge right now in thinking about privacy engineering, is more of an initial about this concept because the privacy world is still looked at as if it's very small or like a subset or a very small adjacent thing to the security world. But, that's not true. This is this is absolutely something which is, you know, expanding and absolutely relevant right now. I would say even more than normal security.
Debra Farber 25:26
Why do you think more than normal security? Is this just because of the sensitivity of data? Or....
Suchakra Sharma 25:31
Yes, yes, because normal security bugs are going to hurt the bottom lines of companies, but this is actually going to hurt people. So, I believe the PII data of people getting somewhere else. And I'm just telling you, yesterday...day before yesterday, I think, there was a news item where mental health data of people was leaked, you know, and that's absolutely a dangerous thing because now it it hurts them. It stops their growth. They can be discriminated against, you know, but otherwise, in security issues that have happened before, remote code execution happened in some machine. Okay, fine; the system was down for, you know, 100 days. It's fine. It costs something to the companies and it's over. But, this is something which actually hurts people. So, I believe this is this is more important.
Debra Farber 26:21
Yeah. I mean, I think that's, it's a really great point. And it's something I always preach is that, especially with data scientists who are always you know, they're looking at large numbers and analytics about, oftentimes, people and that there's this perspective of being excited about what you can figure out, but you have to instead think about, what are the potential things that could go wrong and what privacy harms are we trying to avoid? I try to avoid the term 'user.' It's 'humans' that are behind systems.
Suchakra Sharma 26:48
Yes. absolutely
Debra Farber 26:49
And we need to remember that.
Suchakra Sharma 26:51
Yeah, humans are going to be affected; so, we need to remember that.
Debra Farber 26:55
Right, right. So then, what advice would you give to engineering managers in...I say, engineering managers because there's so few privacy engineers or people with that title. So, it's the engineering management that needs to kind of realize that they need the privacy expertise and either hire engineers that work on privacy-related stuff, or hire 'privacy engineers' that are architecting and building for privacy features. But, what advice would you give to engineering managers to move the needle on privacy in their organizations?
Suchakra Sharma 27:27
I would say engineering managers, as well as the whole engineering function that now has to lead privacy. So this is the correct time for them. So, you know, those engineers, as well as the engineering managers who have have been sitting with them developing these tooling, they are the builders of these platforms and they need to take matters in their own hands now, not just shove it away to consumers or to other, Legal, or other verticals in the organization. No, that's not what it's supposed to be done.
Suchakra Sharma 27:59
They are the builders of these platforms, and they need to take matters into their own hands. That's what I absolutely believe. So, they have to build apps from the ground up. They should respect privacy. They should prevent the spillage. And, it is the privacy engineers and developers who actually understand the intricacies of these apps, so they can actually help fix these bugs early on. So, I would tell them, "Please, get tools; sit down; focus; and, look at privacy as a first-class citizen in your organization" because, if you don't, it will monetarily hurt you and it will hurt your users, eventually.
Suchakra Sharma 27:59
So, org also need to build some resilience structures that gives tools to these engineers to find these privacy bugs. So, just like an engineer will tell their developers, "Hey, you have to fix all the buffer overflows inside this system." You know, "Sit down and debug the code." It's the same way, you know, there should be "Fix a PII leak," you know, "inside the code. You're using this variable, you should absolutely understand what data is going to contain & where this data is going to flow, so have this understanding very early on." So, I believe that's that's absolutely essential.
Debra Farber 28:59
Yeah, I think that makes a lot of sense. And, how do you see it right now? Do you see there being a lot of movement across engineering teams in trying to get privacy expertise to address these things, or is it still really slow-going and....
Suchakra Sharma 29:26
I think the movement has become much more, you know...it has picked up pace, I would say. This, I've seen in security also before where this whole concept of why should developers care about the 20 dependencies they have? Or, why should they care about this little bug like an SQL injection that they have added here? So, they will not care about it, you know, because this was completely offloaded to the security function of the organization. And, things were very much working in isolation in those spaces. But, what changed eventually was the concept of security education. So again, thanks to the huge increase in the bug bounty sphere that you have been discussing, Debra. So, I think that and developer education and security education is now back in the forefront. And, it's same thing is happening to privacy also at this time.
Debra Farber 30:25
Yeah, I just wish it would just hurry up, right? Because I...like, I already could see the path forward; it's just gonna take a while to steer that ship, turn it around a little bit. Before, we close for today, are there any conferences that are coming up of interest in this space or events or research or communities that people can plug into - more around static code analysis and privacy - that you want to share?
Suchakra Sharma 30:50
Yeah, I know a few of them. So, I believe USENIX Enigma is an amazing event for privacy, which is specific to privacy. There is also a group, IAPP, that has like an annual conference and they have many chapters also all over the U.S. and the world. So, that's also an interesting venue, as well as an organization, to latch onto. There is also an academy conference, very academic in nature, so research like conference. It's called as Computers, Privacy, and Data Protection: CPDP. It's going to happen in 2023 in Brussels in Belgium. I mean, these are some of the venues we should track. There are some others. Also, normal security conferences also are now having privacy-specific tracks. So, I believe those are also interesting.
Debra Farber 31:43
Great, great. Well, Suchakra. Thank you for joining us today on Shifting Privacy Left to discuss static code analysis and privacy; and how you can build a system, an automated-machine for discovering privacy violations at scale. I'm certain, I'm going to have you back on the show in the future to talk about how this space is evolving; but it's been a pleasure talking with you.
Suchakra Sharma 32:07
Thanks a lot. Thanks a lot, Debra. I really enjoyed talking to you on the podcast. Thanks a lot, again.
Debra Farber 32:14
Absolutely. Well, until next Tuesday everyone when we'll be back with engaging content and another great guest.
Debra Farber 32:23
Thanks for joining us this week on Shifting Privacy left. Make sure to visit our website shiftingprivacyleft.com where you can subscribe to updates so you'll never miss a show. While you're at it, if you found this episode valuable, go ahead and share it with a friend. And, if you're an engineer who cares passionately about privacy, check out Privado: the developer-friendly privacy platform and sponsor of this show. To learn more, go to privado.ai. Be sure to tune in next Tuesday for a new episode. Bye for now.
.jpeg)
