The shift left movement has pushed more onto the developer’s pipeline including security. However, with the challenge of securing mission-critical applications and navigating cloud and edge environments, security can often present difficulties for developers. There is an increasing need for security at a code level, and one of the ways to do this is by integrating security solutions into the developer’s environment.

BluBracket recently announced an enhancement to their code security solution, claiming it makes the most effective and complete solution to protect enterprises from supply chain attacks. The enhancement aims to help developers identify and eliminate risks in code reducing the attack surface of the software supply chain.

In this episode of TFiR Let’s Talk, Swapnil Bhartiya sits down with Casey Bisson, Head of Product and Developer Relations at BluBracket, to discuss the challenges of securing code for developers and why it is important for them to have the right tools to understand and fix security problems.

Key highlights from this video interview are:

• BluBracket protects software supply chains by preventing, finding and fixing risks in source code. One of the key challenges of securing code is there is too much noise and false positives, making it difficult to see the real vulnerabilities. Bisson explains how BluBracket secures the entire workflow.
• The changing landscape of how we develop and deploy applications presents a number of challenges, from navigating the cloud to securing mission-critical applications. Bisson discusses the security challenges developers face today and how we can empower them to treat the security of their code as a quality issue.
• Although bugs are a part of the software development process, there is a human aspect as well as a technical aspect to consider. Bisson explores the role humans play in security and why it can be challenging to talk about secrets in code as a risk.
• Bisson shares his insights into the importance of developers understanding the software supply chain and securing it. He explains the risks of using components that were not built by the developer. Vulnerable components can also lead to attacks, and problems have arisen from developers taking legitimate components and changing their behavior.
• With the shift left movement developers with more being placed in their pipelines, but it’s not just a case of working with modern code, there is still code from 40 years ago. Bisson discusses how we can navigate the evolution of code, improving efficiencies and constantly building skills and evolving to ensure vulnerabilities are found.
• BluBracket initially started by focusing on secrets in code, but has since expanded to giving developers feedback on the security outcomes of fixing issues. Bisson shares why he feels it is important to give developers the tools they need to fix security problems and receive that feedback.
• Security teams can hold things up when telling developers how to rely on security. Bisson explains why it is important when building solutions that other teams allow developers to secure things in a way that doesn’t affect velocity, and why that improves the outcomes.
• Bisson shares his best practices for organizations to follow so that the code their developer is writing and deploying is secure.

Connect with Casey Bisson (LinkedIn, Twitter)

Learn more about BluBracket (LinkedIn, Twitter)

The summary of the show is written by Emily Nicholls.

[expander_maker]

Here is the automated and unedited transcript of the recording. Please note that the transcript has not been edited or reviewed. 

Swapnil Bhartiya: Hi. This is your host, Swapnil Bhartiya, and welcome to another episode of TFiR Let’s Talk. And today we have with us Casey Bisson, head of product and developer relations at BluBracket. Casey, it’s great to have you on the show.

Casey Bisson: So great to be here. So great to be talking about security with yourself and with your audience. Thank you.

Swapnil Bhartiya: Yeah. And you folks recently announced enhancement to your code security solution. You folks at least make that claim that it makes the most effective and complete solution to product enterprises from supply chain attacks. Now, we will of course talk about how valid those claims are. But the fact is software supply chain is becoming a very, very serious topic. There are so many factors that are there. We will talk about that as well. But before that, I do want to understand a bit about a company itself, to talk about what do you folks do because security is a big, massive area and what are the areas that you focus on?

Casey Bisson: Absolutely. So BluBracket was founded focused on the other half of people’s code security problem. We all think of code security typically in terms of the risks in the behavior of the code, similar to SQL injection attacks and things like that. The other half of that risk is actually the secrets, the intelligence in the code about what it connects with and the passwords, the keys and everything else that it uses to make those connections.

That risk in code is actually half of all the risks that you’ll find. And that’s the foundation of what BluBracket we set out to solve. But as we got there, we discovered that the problem that developers face when trying to secure things is not discovering. Security teams, developers, everybody who’s trying to secure something face this problem with too much noise. And it isn’t just false positives, it’s just too much noise about things that are showing up in tests and scans, people coming in on bounties. And are these real vulnerabilities? And most importantly, how do we actually get them fixed?

And so what BluBracket really focuses on is that entire workflow for how we secure things. And what we discovered is this incredible focus in these conversations about supply chain security are focused on the dependencies that people have with less focus on the internal supply chain. And that internal supply chain is not just your code, but it’s also who has access to your code and where that code is going. And so when we look at that, when we look at the dependencies, the risks in your code, the risks related to access and the risks related to where your code may be going, and this isn’t just data loss prevention, most code leaks are completely accidental. But when that code has secrets and other risks in it, people need to know. And so securing that entire workflow. That’s what we talk about when talk about the complete and most comprehensive code supply chain security solution.

Swapnil Bhartiya: First of all, thanks for explaining such a deal. This is a topic in which we can sit down and peel a layer of onion when it comes to especially software supply chain. So it’s kind of challenging where to start the discussion. So let’s just start with some of the basics. If we look at today’s businesses, the way we deploy, develop applications is changing. We still have on-prem. We have cloud, we have edge, a lot of mission critical or you can say, sensitive. Everything is sensitive in today’s world, all the way from Tesla cars to whatever you do at URINGO, IOT device.

So if you look at this changed landscape, what kind of challenges do you see that businesses face today which can be really though… Because when you talk about security, not only does it take your service down, it can disrupt a lot of things. It can also compromise user data and it an… Nothing will ruin your reputation than a big security hack or compromise.

Casey Bisson: Absolutely. And we’ve seen so many security hacks just this year, really accelerating in their velocity. The way Lapsus$ moved through so many attacks this spring is kind of amazing and it really reflects the risk of secrets and code because there’s two methods of their attack. It was both very substantial social engineering aspects and to get into access to these things and then using the secrets and code to make adjacent attacks and lateral attacks beyond that.

And so that really represents sort of the risk. But I don’t want to talk about what people should fear because we all have way too much of that. One of the things that I see that companies really face is a lot of security companies saying developers don’t care about security, and my experience is that that’s absolutely not true, every developer I’ve met views security. And I come from a development perspective, but every developer I’ve met talks about security in terms of the quality of their code. There’s no developer out there who wants to ship something that does not meet a level of quality that they can respect. And so their self-respect as developers is dependent on shipping quality code. And when security is part of that’s what they want to do. What they don’t have time for is somebody from a security perspective trying to get in the middle of their effort and their responsibility to turn business requirements into a product. And that’s the biggest challenge developers have.

And so how do we empower developers to treat the security of their code as a quality issue, not something remote and honestly, very, very abstract? And so the more we can do to provide real time feedback inside the CICD pipeline so that developers can see as they’re committing in their ides and as they’re doing pull requests, get some feedback about whether or not this code maybe has risks that they want to consider looking at. And when you automate that, especially in the pull request, you can elevate the conversations because you’ve represented as a team that you care about security, you can elevate the conversations in the code review from being the things that nobody wants to do.

Code reviews that focus on style are wasted code reviews, but when you have something that automates some of the identification of basic risks, then you can have good conversation between reviewers and the developer about what is the right architecture for security. And by just having that guidepost, these are the basic security things that you’ve fixed. That gives the developers a huge amount of guidance and those conversations that can emerge from that really empower developers. And it says, we care about security here. In the same way that having pool request feedback about whether your test coverage has increased or decreased as a proxy for judging code quality, that’s incredibly valuable for developers as well. “Hey, this is great code, but can you write those tests” is something that people can do. And then people can say, “Yes, let me make sure I get those tests. Is that something that has to be done before merge?”

Now substitute that with a security conversation. Do I need to fix the security problem before I merge it? And the question answers itself? So yeah, your question is what is the biggest challenge that teams face as in the security environment? And the biggest challenge is the developer who is given those business requirements to turn into a product and doesn’t have the tools they need to and the guidance they need to secure it.

Swapnil Bhartiya: Once again, thanks for focusing on developers because that’s where the buck stop. Before that, you were also talking about what kind of… I do want to talk quickly about what kind of security risks are there because unless until we identify the problem, we cannot even look at the solutions. Of course, bugs are part of software development process. As long as we are writing software bugs will be there. But in most cases, as you’re also talking about, it’s social engineering. It’s misconfiguration that is unnecessary access. That’s where the problem happens. So it’s more the things are happening at human side, less on the technologies side.

So how do you look at it? And that will actually gel very well with, as you’re talking about, enabling developers, not gates, but guards kind of things. So talk about that.

Casey Bisson: I love how you position that. The human factor is an incredible factor in security. Anytime somebody measures this, the only way the technical factors become significant over the human factors is if you ignore the human factors. So you are absolutely right. There’s so much of this that we have to pay attention to. And I actually classify. When I talk about secrets and code as a risk, I think a lot of people really misclassify that because we don’t have good language to talk about it. And so is it a human factor because it’s what humans can find and then use when they read it or is it a technical factor because we use it very effectively.

So we have to look at that whole range of risk and your perspective is really good there. What we find is that when we can give people away, and this is what we do in our product, when we give people away to view a comprehensive set of risks and prioritize between them, rank them by severity, developers can get the credit they need by fixing risks one by one, knocking them down and bit by bit you fix this. It doesn’t matter exactly what the risk is, it matters that we fix them over time. And empowering developers to do so is exactly what I focus on.

Now, that doesn’t solve the human risks, but the more we’re aware of security, I think the better we do on the human risks as well.

Swapnil Bhartiya: Excellent. Yeah. I mean, I love this conversation the way it’s focusing more on the actual problem areas, not just…. Now, I want to quickly also talk about software supply chain because it is a bit different than the traditional security that we talk about. Number one is that we talk about shift lefts. So a lot of things are moving towards developers pipeline, which brings back to the point that you were making initially. Second is that today’s world literally kind of runs on open source software, which also means that not only you are using different projects that come from different foundations, companies, individuals. Within those projects, there are different frameworks, different libraries. Then there are different GitHub repositories for the same package maintained by different maintainers. It’s just like the best analogy is either cooking food or a car assembly line. If you do not know where the core companies are coming from you cannot secure risk.

Also talk about the importance of understanding software supply chain especially for developers so that they can help improve their security posture.

Casey Bisson: You know, I love the point you’re making because the reality that there are so many components that we’re using. As developers, we know that the fastest way to a solution is not to build it but to use it. And everybody has learned, I think, and internalized this build versus buy thing. And we know that if there’s a component out there that’ll get us the solution, all of us have been taught for a long time now that we have to use what’s out there unless there’s a really good argument for why not, that we believe in.

So we as developers we’re building things from large numbers of components, and I am guilty of this as well. I find something, I add it to my assets and it turns out I’ve added the wrong thing. It’s either the wrong package that has similarly named or it’s the wrong package that somebody’s typo squatting on and doing social engineering attack on me to convince me to use their hacked package. And so there’s that risk.

There’s also the risk of vulnerable components that are truly legitimate components but they have vulnerabilities. I want to break those two things apart. Attacks on the supply chain by people trying to inject things through typo squatting and other things. I think we’ve seen a lot more of that over the past year, but it’s not that new. And those attacks where people finding a vulnerability in a library component that is used in many, many places.

And then there’s a third one we’ve seen unfortunately really emerge this year with developers taking components, realizing that they can make a message. And so they change a perfectly legitimate component and change its behavior in a way that’s completely unacceptable. Those three are huge but they represent your external risk. And the great news is the open source community, thanks to an incredible effort by so many people, individuals and as well as companies, is really good at finding these vulnerabilities.

The thing that keeps me up at night is all the code we write internally that doesn’t have all those eyes. Open source I think overall is more secure on average than the code we write internally and it’s because of the extra eyes on it. When we write our own code we don’t have the benefit of that community guiding us. We depend on the team that’s reviewing it with us. And there’s often times a lot of historical code, a lot of legacy code that just doesn’t have the same kind of eyes.

And so when I think about that supply chain, there’s so much stuff that we bring in but the risk doesn’t stop at the front door, the risk continues. We have to be as vigilant with our internal code as we are with our external code. Not only what’s in that code, but also who has access to that CICD pipeline. Who has access to the code, who access to the build machines, who has access to those assets and then where does that code go? As I said at the beginning, most code leaks are completely accidental. But when people discover secrets because of a code leak, that’s a problem.

Swapnil Bhartiya: You talked about open source is relatively more secure, it’s better because there are more eyes. Just the fact is that I don’t know if you actually said that, but given enough eyeballs or bugs are shallow, which in some cases is not actually true because if you look at open source, there are a lot of bugs which have been around for decades. So if there were enough eyeballs, why the vulnerability still there? I think enough eyeballs is not important. What is really important is some trained eyeballs looking in the right place because you can have all the folks looking in the wrong directions, it will… So there’s also a street lamp effect where you’re looking at the problem where you expect it to be and that’s where it is not.

Second thing is now I was reading an article also, especially the Open Source Summit, security was once again the topic, was that we cannot take for granted that open source is secure. A lot of securities once again moving into developers pipeline is becoming their problem. There’s already a lot of burnout happening. Folks are getting burned out because everybody’s moving the cloud everything.

I mean, as much as we like to say, “Hey, we are empowering developers.” The fact is we are moving a lot of things into their pipeline earlier. You know what? You write the code, you test it, it’s working, you’re done. Operators will deal with it. Security will secure it. Now everything is your problem. So like most of the time they are treaty people. They want to solve a problem and move on. Now, the code they wrote three years ago they still have to make sure that it’s safe and secure, which is actually I think counterproductive.

At the same time, we did talk about the whole DevOps movement where we are breaking the old silos. But the fact is we still have silos. We have security teams. We may change the names of them, but it’s not like… Also some is specialization. You cannot have genetic developers trying to do everything. There will be folks who knows about networking. There will be folks who know storage. There’ll be folks who know about security more. So can you talk… Sorry, it’s the long spiel. I will cut a lot of pieces out there, but the point that I want to make it that in this world where we do see shift left movement where we are trying to break old silos but still there are silos, what is the role of a developer when it comes to security vis-a-vis is the role of security team vis-a-vis is the role of DevSec Ops team?

Casey Bisson: Absolutely. It’s a huge question. There’s code running. We know that there’s code running out there in the world from 40 years or more ago and it’s still in use. Everybody likes to point to banks and their historical legacy systems. It goes beyond that, I know. But the real challenge here is how do you take… We know that there’s vulnerabilities in old code. How do we protect it is one question or, and I wish I could remember who said this, I wish I could credit the right person, but the commandment was one of the rules of development at scale is always be migrating. No matter what you’re doing, there’s always a reason as you’re scaling, you need to be migrating so you can help eliminate the legacy code by continuing to migrate.

You’re going to fix it. You’re going to improve efficiencies. You’re going to build the skills among your newer developers or junior developers to build and rearchitect things the right way. And so you’re building this capacity and those teams that are always migrating never have the challenge of having the face old code. Now that’s a wonderful world and I don’t think every place can do that. And so we have to look deeper for some better solutions. Right now what I can offer, what I’ve seen works is giving people real time feedback in that CICD pipeline, in the IDE when they’re committing or in their pull requests, giving them feedback about the basics of security, the things that you can identify programmatically.

Those things are really, really valuable. When code is being touched, giving them that guidance. And that’s where people learn. That’s where people have those conversations, as we talked about, about what is security and how to get there. And that’s the best solution. That’s the most effective solution I’ve seen so far.

Swapnil Bhartiya: Excellent. Now, we have talked about the problem broadly. Let’s kind of zoom back to BluBracket. Tell us, how are you folks trying to solve this problem to make once again… The whole idea was to make things easier for developers so they can focus on solving business problems. So talk about how you are helping organizations and developers?

Casey Bisson: Absolutely. As I shared, we started out being focused on that other half of the security problem, secrets and code, but we expanded from there. We talked about how the importance of giving developers feedback because we realized really early on that it’s not the discovery of issues that is the problem, it’s actually the outcomes, the security outcomes from fixing them. So many tools. We’ve had SAST tools. We’ve had TruffleHog for a lot of years and still we have these problems. And what is the issue? It’s discovery is easy. Fixing problems is hard.

And so giving developers the tools they need to actually get things fixed, to be able to monitor their progress, get real time feedback about those fixes, get the credit they need from their leadership and build the support from their teams. We’re out here trying to fix problems and here’s how you can see what these problems are. Developers need these tools. Shift left fails when it’s a security team going to developers and saying you got to secure things. That’s not an actionable thing. But what developers can actualize on is when they get the feedback, addressing that feedback. And when they get a way to measure their performance, doing that, solving those issues.

And so that’s what we look for in our product. That’s what we look for to build success, build better security outcomes with the teams that we work with.

Swapnil Bhartiya: Also when security team goes and tells developers how to rely on security, that slows things down, the velocity decreases. They cannot move at the same pace they want to or they must move to stay competitive as well.

Casey Bisson: Absolutely. Developers have this impossible task to turn those business requirements into a product. Anything that gets in the way of that, they’ve got everybody on the product side, the CEO, everybody angry and wondering what’s slowing that down. When people say developers don’t care about security, it’s not that they don’t care. What they don’t have time for is people getting in the way of their productivity. So building solutions that allow them to secure things in a way that doesn’t affect velocity, that’s what’s needed to improve the outcomes.

Swapnil Bhartiya: Excellent. Now my last question is going to be more of more like summarizing what we just discussed and to also kind of share, not necessarily a play book, but just share some tips or best practices that organizers should follow so that the code their developer’s writing and deploying are secure. What would you advise?

Casey Bisson: I love the question. You know, I’m going to start with the basics. Start with pull request workflow, require sound commits and actually have conversations about security. Figure out what it takes to encourage those conversations. We found that just having automated review on every pull request can help an incredible amount. Advisories about security, not blocking, not blocking. We found in our work with our own customers, advisory reports about security get 80% compliance. And because they’re just advisory and because people are learning from it, the participation in these tools grows dramatically.

We found it’s the opposite when you try to enforce things, if you block commits, if you block pull requests based on these things. People hate it. But when you give people that advice, their security outcomes improves, they grow. And I would really start there.

So basic security things, sign commits, pull request workflow, and give automated early often automated security reviews.

Swapnil Bhartiya: Casey, thank you so much for taking time out today and talk about of course the company. But more importantly, the problem that deal. And I also loved about that you don’t want to talk too much about the fear factor. Security, everybody tries to make it. In most cases security companies sound more like insecurity company. They want you to feel insecure about code. But thanks for talking about the areas that it really matters, which is developers. So thanks for sharing those insights and also thanks for sharing some of the tips that [inaudible 00:23:27] should follow to have a better hiking there.

And I would love to have you back on the show because we said there’s so much to talk about. Thank you for your time today.

Casey Bisson: Absolutely. Thank you for having me. Thank you for the great conversation and I really appreciate having a chance to talk with you and your audience.

[/expander_maker]