The software supply chain encompasses anything that goes into your software, the components, and anything that impacts your code as it goes from development to production. This includes having visibility into the code of open source and third-party dependencies and being able to prove their provenance. Ensuring the delivery pipeline is secure and whether it maintains a full software bill of materials (SBOM) helps to provide visibility.
Palo Alto Networks’ Prisma Cloud Supply Chain Security, provides graph virtualization helping developers discover potentially misconfigured infrastructure and application files. Developers are able to see a full threat model of their entire application, and can see the impact any code changes would have on it before you are committing the code
While security best practices and securing the development lifecycle can go some way to ensuring a secure application, the digital transformation organizations have gone through migrating from a monolithic system to a microservices-based system has also changed the way software supply chains are secured. This progression has generally been a positive change (although challenges still remain), as developers now have the ability to scan, understand and fix problems and vulnerabilities early on in the development lifecycle.
Barak Schoster, Senior Director, Chief Architect at Palo Alto Networks, believes that this development in software supply chains has brought about a cultural change in organizations. Whereas previously, tools and knowledge on how to secure an application typically remained in the hands of security teams, by putting the security tooling into the CI/CD pipeline, democratizing the knowledge, engineering teams can now access and better understand securing their applications.
About Barak Schoster: Based in Tel Aviv, Barak spends his time helping teams secure cloud infrastructure. He is the creator of Checkov and often contributes to other open source projects. He has previously worked for RSA, focused on cybersecurity machine learning and big data architecture, as well as at Fortscale and IDF tech unit.
About Palo Alto Networks: Palo Alto Networks, the global cybersecurity leader, is shaping the cloud-centric future with technology that is transforming the way people and organizations operate. Our mission is to be the cybersecurity partner of choice, protecting our digital way of life. We help address the world’s greatest security challenges with continuous innovation that seizes the latest breakthroughs in artificial intelligence, analytics, automation, and orchestration. By delivering an integrated platform and empowering a growing ecosystem of partners, we are at the forefront of protecting tens of thousands of organizations across clouds, networks, and mobile devices. Our vision is a world where each day is safer and more secure than the one before.
The summary of the show is written by Emily Nicholls.
Here is the full unedited transcript of the show:
- Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to TFiR Lets Talk. Today we have with us Barak Schoster senior director and chief architect at Palo Alto networks. Barak it is great to have you on the show.
Barak Schoster: Thank you for having me.
- Swapnil Bhartiya: Today’s topic is something which is closer to my own interest and our audience, which is soft supply chain security. But this is also a thing which I may be wrong. Also, needs a lot of awareness and education as well. So if I ask you, how would you define software supply chain?
Barak Schoster: So software supply chain composites, all the different pieces that as a business that builds application, compose the application that we build. So it can be third party software like open source packages that we’re using, containers that we’re bringing from the internet. The code that we’re writing by our own, either by contractors or our own employees and engineering teams. Also the delivery pipelines themselves. So, when we deliver new applications to our customers, we should ask ourselves, “Is the delivery pipeline secure?” And do we maintain a full software bill of material called an SBOM, on our entire software and its supply chain, including third party vendors.
- Swapnil Bhartiya: Why should companies care about software supply chain? What is the importance?
Barak Schoster: So, let’s take this piece of software supply chain into another supply chain, cars. Henry Ford built the car built the supply chain, said, “we need a wheel, we need an engine, we need electricity.” And third party vendors built the engine or the wheels or other parts of the car. On software, we started to do the same, we’re using third party pieces, open source packages, containers to build our own applications.
Now let’s say that, you buy a new car and you realize that one of its parts coming from a third party vendor is not what you really expected. You got a flat tire instead of one with air in it. It’s not safe to drive in that car from that moment forward. Or let’s say that your engine got broke because it lost its warranty. So it’s similar on a software supply chain.
You’re using an open source package that is not maintained by the legitimate source, not maintained by a legitimate vendor. And you need the tools to examine your software and realize that very early on. So, software supply chain is a problem that today is not only the problem of security practitioners, but also the problem of the engineering teams. And as part of the shift left movement, a lot of those problems can now be solved very early on. So in bridge crew, we started with scanning infrastructure code, which has its own supply chain risks and over time expanded to the delivery pipeline itself and the application software, including open source packages and their vulnerabilities.
- Swapnil Bhartiya: Let’s just talk about that. This is a problem which is in general for any software that is written out there, it has nothing to do with just open source as valid.
Barak Schoster: Correct, you can use a third party vendor, for example, there was an attack on a vendor that we all used to use called SolarWinds, and a very popular APM, a monitoring software. This attack was detected by the fire eye security team and they’ve identified that the software of SolarWinds was mail form and leaked data that it’s on their customers. So SolarWinds is a propriety software.
A lot of engineering teams can use it and it was fixed since then it’s important to say. But in a specific version, you might have data leakage if you use the bad version of SolarWinds. So it can happen on APM software that you’re using. It can also happen on CI software that you’re using. Codecov is another attack that happened last year. Codecov is a code quality scanning software, which made sure that your test coverage over your application is, whatever you have expected to be, high let’s say. But it also caused some leakage of secrets from your CICD pipeline, which is one of the new crown jewels of application delivery.
So even paid software or open source software can have vulnerabilities and it’s because everybody can make mistakes. It’s not always easy to follow the security best practices. One of the things that we try to do is to reduce that friction and to make it simple to every engineer out there to secure their development lifecycle.
- Swapnil Bhartiya: We are hearing a lot about supply chain security. What led to this surge in discussion about this topic? Because if you look in Cloud the word security is different from traditional IT we have started. Hearing a lot about security in the Cloud work, but why so much about software supply chain and as bombs now?
Barak Schoster: So one motivation for that is the recent attacks that are very sophisticated, that we’ve seen in the past two years over the entire supply chain from open source packages to the configuration of version control system itself, to the CI workflow system itself. But also, a lot of organization went through this digital transformation, breaking monoliths into microservices, changing and modernizing their Cloud infrastructure.
It introduces a new set of risks and also a new set of opportunities on the Cloud everything is API driven. When we declare everything on infrastructure is code, it’s now declarative and version control. For the first time we have the ability to scan, understand and fix it early on. We didn’t have that capability when everything was, and monolith did not have an API, everything was proprietary.
It was really hard to secure it, and it was really hard to make it streamlined as part of your agile sprint as an engineering team, it was very waterfall oriented and you had the ability to release software only once a year or twice a year. But now when you are releasing software multiple times a year, you really need a solution that will scan every change of your code base of your software bill of materials. And the only way to jump on these new cadences and this new velocity, is to have a new solution that will scan continuously your software.
- Swapnil Bhartiya: How developers can help, kind of improve the security posture of the company?
Barak Schoster: For the first time, since we brought everything into code and everything now is declarative. The open source packages that we’re using are declarative in the package managers. The infrastructures code is declarative and the containers are persistent in a declarative way, both in IT and on the different registries. It introduces the ability to put scanners in your CI pipeline, and linters that will tell you, “Hey, you have a mistake over here,” while you are writing the code. So either on your ID, your VS code and JetBrains.
So you’ll have the ability while you code before even you are committing the code, to see where you have issues and how to fix them. The second phase would be to put those tools, those scanning tools in your CI pipeline, and to fail a build, stop it and fix it, before it arrives into a real environment, into a production environment. Also have a poor request process where different teams can collaborate and review.
And also automatically you solve those tools to automatically review and fix your code base. It brings in a cultural change. Before that security teams were siloed and they were the smart guys that knew how to secure your application. But once you’re putting the security tooling into the CICD pipeline, you are democratizing this knowledge. Now, any engineer can understand, Hey, I have issue in this code lines and this is how to fix it, and now I have the context and I’m educated not to do the same mistake again, I’m more productive and I’m fixing it before it’s arriving to a real environment. So, less JIRA tickets, less unpredicted work, less burnout.
So it’s a really positive revolution on the engineering team to get this kind of responsibility. And it happened in the past already, like 15 years ago, we had the democratization of unit testing of the QA profession into the different engineering team. Now engineering teams are writing automated tests. On the past two years, that’s the revolution that is happening for security teams. Engineering teams are starting to write the security test to automatically scan them in a continuous fashion.
- Swapnil Bhartiya: Since you talk about automation, I’m kind of curious about this topic because once again, that is a topic I cover closely, which is the role of AI ML in security.
Barak Schoster: In the context of operations you can use AI and ML to understand, “Hey, I have a repetitive issue over here that occurs in my dev environment. Is it real? Is it noise?” And it really helps you to understand what’s the real issue in your haystack of alerts that can arrive to dev or production. That’s one way to use that. Another way to use that is you can use AI to understand where a bad code can be fixed by a good code.
So one example for that is copilot that GitHub have launched, who can actually help you write better code and all also in Bridge Group, we have a feature called smart fixes that does something very similar to the space of DevOps code of infrastructures code. So let’s say that you’re writing a new terraform script or cloud formation or Kubernetes script.
While you write this Yamo, Bridge will identify, “Hey, here you have a mistake, but in the past other team members in your organization have written good code, let’s see if you can use those as recommendations to fix your code, by the best practices that are used in your enterprise.” So that’s another interesting way where AI can actually be a recommender system that will fix your code while you’re writing it.
- Swapnil Bhartiya: How can this new, this CICD based workflow, can help developers in better coordinating with other teams. Because security is not a problem of one team, it’s a problem of everybody’s team?
Barak Schoster: So different teams have different KPIs in the engineering organization. The full stack team is responsible for delivering the business logic as fast as possible to the new release of your application. But we see full stack teams are touching in the code base, the Docker files, and they’re using Docker images for local development, for testing. And the way that Bridge can help the full stack engineering teams is to scan those Docker files and tell you, “Hey, you have an issue there you’re using your wrong open source package.
You should bump it to the secure version of it,” or you even have a misconfiguration in the Docker file itself, like you’ve exposed the port, or you enable the root user as the default user of your Docker image. And for the SRE teams, those are the themes that are creating your cloud platform infrastructure. Also named as platform engineering itself, the enterprises, and the platform engineering team can use the tools that Bridge provides to scan their infrastructure, their Kubernetes clusters, their Terraform code, their cloud formation code in every steps of the delivery pipeline. While coding before applying to production on the applying phase or in the admission control phase.
And to have those last guardrails before applying a very misconfigured deployment, and in runtime the ability to continuously scan your cloud environment and to verify if there are any drifts from the blueprint that you’ve defined in your code. So we see SREs and full stock developers really using our tools to be more productive and to reduce the burnout and the amount of unexpected [inaudible 00:13:51] tickets in their backlog, coming from the traditional security practices.
- Swapnil Bhartiya: Now let’s talk about the new third modeling visual edition. How does this help teams in once again, improving their security posture?
Barak Schoster: So let’s say that you want to deliver a new web application, and it’s a basic three tier app. You have a database, you have your compute servers and you have your CDN. You can have mistakes all over it. You can have your database public, you can have your compute with exposed port or unencrypted, using unencrypted volume or an outdated container. What we’ve done is we’ve released a new feature called supply chain graph, that enables you to see a full threat model of your entire application. Understand where in the code there was a change, for example in your infrastructure, that declared a container that is using a vulnerable open source package that is deployed into this cloud server.
This full threat model enables you to prioritize, “Hey, is that really critical? And what’s the butterfly effect, what’s the entire threat model or attack chain that is possible as a result of this change.” And this is where this new feature called supply chain graph is coming to help you as an engineer, understand the impact of the code changes that you’re doing on every step of the way.
- Swapnil Bhartiya: But I’m always curious about the direct impact on developers’ lives, how it makes their life easier. So if you can just quickly give us, hey, this is how it changes your lives?
Barak Schoster: Hmm. Nobody likes to get a pager duty on a Friday night. That’s your day off. That’s your time off, you want to be with your friends, with your kids, with your families. When you get this call of a production issue, it’s really pissing you off. So the best way to undo it is to write good code on the first place. So shifting left of those issues handling to the phase that you’re coding, will prevent from those issues happening in production. As a result will prevent this pager duty alert on your Friday evening.
So, that’s how we improve the quality of life of engineering teams. Also we make all of those application more secure. So from business perspective, your business is more secure. Your application that you’re writing is more secure and your work life balance is better.
- Swapnil Bhartiya: Barak, thank you so much for taking time out today and talk about not only this topic, but also how Bridge Crew Team at Palo Alto are helping developers improve their life, and so that they can have fun on weekends and not have to worry about pagers. Thank you for those insights, and I’d love to have you back on the show. Thank you.
Barak Schoster: Thank you as well, have a good one.