Deb Radcliff interviews Christian Simko, Director of Product Marketing at GrammaTech
Defense-in-depth is critical to protecting valuable digital assets. But instead of the outside-in layered techniques traditionally associated with IT security, software must be protected from the inside out, says Christian Simko, director of product marketing at GrammaTech. That means planning for security before the code is developed, following best practices throughout the development process, and testing until the software is ready for release.This isn’t as easy as it sounds, given how many developers, third-party code elements, and open source components are involved in the development of today’s commercial off-the-shelf software (COTS) applications. In this interview, Christian shares his model for software defense in depth and offers some best practices and advice.
Q: What is your vision of Layered Security in the software lifecycle? The traditional layered approach to IT enterprise security starts at the perimeter and layers inward to protect the application and data layer. I see a similar but different approach when applying security layers to the software development life cycle, which takes an inside-out approach. Applying layers is essential as the software code progresses through the SDLC. With a security by design mindset, you continually test as part of your CI/CD workflow to find defects and fix them earlier in development, which reduces risk to users and customers, and is less costly than trying to fix bugs at the end of development when the application is in production.
Q: Why is defense in depth so important for today’s DevOps teams?Development teams are under tremendous pressure to release software on time and on budget. To meet these goals, developers rely on third-party and open source reusable code components to speed up their development cycles. A recent report by Osterman Research found that one hundred percent of widely-used commercial off-the-shelf software applications contained vulnerable open source components.
This is why layering security testing throughout the SDLC is important. Even when you think you’ve made a best effort to deliver secure code, critical vulnerabilities can be hiding in the third-party and open source code you did not develop. Checking third-party and open source components and keeping secure libraries is now more important than ever to ensure a strong security posture for the software you are delivering.
Pro Tip! Click here to view the Osterman Research Supply Chain Survey, which found that 100% of commercial apps contain vulnerable open source code, including online meeting and messaging platforms, file sharing, browsers and other third-party COTS applications.
Q: What do you consider to be important layers of a SDLC defense-in-depth program?
The first layer is in program planning. For example, consider how the application will be used and what sensitive data will be processed, map application interdependencies, code components and libraries it will be pulled from, and so on. As development gets underway, use SAST [static application security testing] as the foundation for DevSecOps to build security into your development process at the code layer.
The next logical layer is at the software composition analysis [SCA] stage, when you move from development to QA and testing. At this stage, you can analyze the makeup of the source code to get visibility into all the code’s components, including third-party and open source. Additionally, you can use SCA testing to determine if the components are introducing risk by checking for security issues, such as known [N-day] or unknown [zero-day] vulnerabilities, and improper versioning and licensing, for example.
Pro Tip! Check out this Dark Reading article to learn the difference between zero-day and N-day vulnerabilities.
Once the code passes through QA testing and repairs are made, the code is then compiled as a binary and prepped for packaging and release. Here’s where I recommend a final software security assurance layer. With the code in binary form, use a binary SCA solution to scan the compiled code to produce a Software Bill of Materials (SBOM) that identifies the use of open source components. This should be done in both the custom code as well any third-party code in the software.
This is also the stage to run a final vulnerability analysis to check for any zero-day and N-day vulnerabilities that may be hiding in these components or the application functions, and remediate them. This step provides a final test and validation to ensure that software that is heading to the commercial market, released into production or embedded into devices does not contain exploitable vulnerabilities.
Pro Tip! Learn how to get an aerial view of software components in a system working together using CodeSonar
Q: What best practices advice can you offer around layered security in DevOps?
Realize that you could be following the best DevSecOps practices, but are still impacted by past technical debt with third-party code and open source components left behind by other developers that you may not even know about. This is why layered security is so important to the DevOps processes.
Don’t let layered security slow you down, though. Instead, integrate tools and testing into your workflow that you already use and understand. With SAST integrated into your CI/CD workflows like GitHub or GitLab or Jenkins, you can continually scan your code to find defects and fix them as you code, making it easy to adopt and more efficient for the development team to address security.
Also, work with IT security as the software is implemented in production environments. Security analysis and pen testing of applications may reveal security issues that were not apparent in test environments. Different team members from development, Q&A and testing and IT security should be fully aligned and working together in the software development lifecycle as additional issues or defects are found.
Finally, don’t lose sight of your mission to develop higher-quality and more secure code. The best way to develop higher-security code is to follow best practices with a defense-in-depth approach.
