 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The average person trusts that the software is secure that they use to bank online, watch movies, make purchases, order dinner, etc. They fill in the captcha; they check the box alerting the website that they are not a robot; they confirm they’re human; and are being “secure.” But what we have all come to realize is that filling in a captcha isn’t going to protect us from software vulnerabilities and supply chain attacks such as the Solar Winds and Colonial Pipeline hacks. Our first line of defense is the developers who write the code.
Developers are going to code at an extremely rapid pace, but how do we close the gap between speedy development and checking that our build info — all the information collected by the build agent, including dependencies, artifacts, project modules, etc. — is secure? How can we accomplish both goals of fast development and deployment while verifying that we are not at risk of an attack? The term “shift left” is widely used to describe bringing security scanning and compliance components to the onset of development, instead of being a costly afterthought, and this is the standard we hope all developers reach.
I sat down with JFrog CTO Yoav Landman and CISO Moran Ashkenazi to find out what it means from the CTO and CISO perspectives for a developer to shift left.
Both agreed that education and upskilling is key to reorient developers, so that shifting left to add security to their development process is no longer a shift but a standard practice.
“As the CISO,” said Ashkenazi, “my responsibility is to empower developers to make the right decisions. It’s very challenging because there is a knowledge gap. We want our developers to understand the breadth and depth of potential security vulnerabilities, to look for the red flags so they can independently make the right decisions and adjust their development accordingly. But sometimes they don’t have the knowledge to do that. It is my job to give them the tools [and] the training, and work with them to expand their knowledge. Security tools put the guardrails in place for the developers so they can better understand if there are vulnerabilities or weaknesses in their code as they develop. Developers should be empowered by security and not blocked — securing the products is a mutual responsibility between the security team and development.”
Landman echoed that sentiment. “I fully agree that we don’t need to block developers, but empower them and make them understand that security is just another form of debugging,” he said. “Developers are excited about gaining knowledge and making educated decisions to avoid risk and costly mistakes.”
“Getting hacked is not just [about] getting hacked,” Landman continued. “Getting hacked can mean going out of business; it can be game over. We are creating more and more software, automating processes, speeding up development release cycles and everyone from consumers to corporations to governments are in a digital transformation phase. We are writing code, adopting others’ code, adding more layers and complexities to our software, [so] the incentive for the ‘dark forces’ is only getting bigger. Practicing DevSecOps, closing the trust and knowledge gaps between devs and security teams, having failsafes in place to help mitigate vulnerabilities, scanning and failing a build before it goes into production when an issue is discovered — [these] are ways we can defend our software. But we need to start at the onset; we need to start with the developer.”
With all the buzzword bingo circulating in the tech community around the software bill of materials (SBoM) and supply chain security, one thing is certain: Software is running the world and there are a lot of bad actors out there looking for opportunities to penetrate vulnerabilities. When they are successful, the outcome is chaos. Consumers lose trust, and companies can pay astronomical costs to repair the damage that was done — or lose their business altogether. Companies need to upskill their developers and supply the tools and training necessary to create a stronger, more cohesive DevOps or DevSecOps team. Security starts with development and education is the shift they need to get their job done.
To learn more about DevOps and other cloud native technologies, consider coming to KubeCon+CloudNativeCon North America 2021 on Oct. 11-15.
