 |
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.
Software developers at large organizations are constantly challenged with new security and compliance requirements that aim to increase the safety of their app development and delivery processes.
However, these new and changing security and compliance requirements are written and implemented by security teams that do not take into consideration their developers’ workflow. The idea of shifting security left has been popularized as a way to deal with this, but even then, it can lead to lost developer productivity and software that is less secure if not implemented properly.
It’s become clear that merely “shifting security left” is not enough because, often all that does is shift additional burdens or decisions to developers, which distracts them from writing code.
An end-to-end approach that focuses on automated controls and tools set by platform and security engineers can help reduce toil, leaving developers to focus on creating the applications that drive business and revenue.
We need to improve the automation around processes for software supply chain security to help developers manage these requirements from build time to production. Enterprise developers need to have tools that provide clear and smart guardrails that are applied constantly and without manual intervention, enabling them to focus on business value.
When it comes to building a secure software supply chain, we should focus on the following five desired outcomes.
When building an application, developers, platform operators and security professionals want to monitor vulnerabilities throughout the software supply chain. The challenge comes when multiple vulnerability scanners are used at different stages in the pipeline and different teams are notified and required to take action without proper coordination.
A security-focused application platform can build in scan orchestration to not only detect vulnerabilities but also to map those findings to a workload. This feature allows developers to identify issues throughout the life cycle of their applications and help them resolve issues, shifting left the responsibility with a higher degree of automation. Moreover, the platform can build trust with security analysts by showing the performance of application developers and helping them understand the risk that teams are facing.
With the right automation, application platforms can help organizations reduce noise by building a richer understanding of the applications and their runtime environment.
Once a platform detects these vulnerabilities, both at build time and at runtime, it needs to help developers triage and remediate them. This in turn reduces the toil created by all the security scanners and pushes the analysis and tooling to the people who know their software the best, developers. Engineering teams can triage the vulnerabilities that are found in the supply chain and leverage platform automation to rebuild their images, mitigating any potentially exploitable issues.
Engineering teams across all enterprises are drowning in security alerts due to the lack of orchestration and alert mapping. However, with the right automation, application platforms can help organizations reduce noise by building a richer understanding of the applications and their runtime environment. Having this automation can radically reduce toil for developers and improve the teams’ security posture.
Since the disclosure of multiple software supply chain vulnerabilities by large software vendors, it has been clear that, as an industry, we need to improve our application integrity processes.
The release and growing adoption of the security frameworks SLSA and sigstore have helped development teams improve their integrity efforts. That said, creating a software supply chain that meets the SLSA requirements and implements strict signatures from development to production is still complex.
Platform teams can create automated supply chains to help developers achieve SLSA compliance. Particularly, tooling and platform engineers looking to achieve this can focus on having basic controls for their build process like:
With these controls in place, teams can achieve SLSA level 2 and move up to level 3 with a build system that can authenticate the provenance information.
SLSA continues to be under development and the community is continuously improving the implementation options.
Supply chain attestations enable developers to show the integrity of their software from build time to runtime. It is authenticated metadata about a collection of software artifacts that can be used to verify their provenance. SLSA has created a model for software attestations that platform teams can use to help developers prove the origin of their code.
In-toto is the implementation of the attestation model used by SLSA. It can be used with build tools like GitHub Actions to create and verify attestations about the build process of applications.
Once teams implement authenticated attestations, they can use them to verify multiple steps in the build process. For example, they can attest that the build occurred in a trusted build system or that the artifact passed an enterprise approval process.
After all the attestations are created, the production environment can automatically verify that all the required steps were taken before the application is deployed without manual intervention and with the confidence provided by cryptographic verification.
Application platforms are required to work with multiple different tools, from vulnerability scanners to monitoring solutions. Integrations with other tools are critical to helping teams deliver secure systems.
Integrations need to be a core feature of a platform. Security is a team sport, and when building automation to help development, operations and security teams, you want all the players to work together.
An application platform with a security focus should integrate and orchestrate tools like vulnerability scanning, dynamic application scanning, runtime application protection and others.
According to the latest Panaseer Security Leaders peer report, security teams use, on average, 76 different tools. Some of these tools require input and interactions from development teams, but enterprises rarely have the orchestration capabilities to provide engineers with the right information at the right time. Even with “shift left” initiatives, developers have to use multiple tools and dashboards, which ends up creating more toil.
An application platform with a security focus should integrate and orchestrate tools like vulnerability scanning, dynamic application scanning, runtime application protection and others to provide developers with the right information at the right time. Additionally, having integrations feed information about the security posture of the application can be used to create policies and perform automated defense tasks that can improve overall security and reduce compliance toil.
Tools like OPA and Kyverno have helped move forward compliance management for application environments to levels that were previously not even considered. These tools help platform operators set boundaries for developers to ensure they stay compliant with their regulatory frameworks and their enterprise requirements without requiring manual reviews.
Platform teams can leverage these tools to create guardrails that are flexible enough for developers to work inside them but that provide the right level of trust for all the different groups in their organization.
Building on previous tools like vulnerability management, integrity checks, attestations and integrations, a platform team can create a rich set of policies that provide a significant level of confidence in the artifacts deployed in a given environment. Having these tools can increase trust between developers, platform engineers and security teams without having to drop to manual processes.
By having these adaptable rules, teams can focus their effort on delivering applications, instead of having to prove the security and compliance of their applications manually.
In his book “Securing Cloud Apps,” Adib Saikali offers insights, sample code and architectures written from the developer’s experience. You can read and download the chapters as they are published over time here for free. Though not mentioned in detail here, internal developer portals are proving to be a great way for platform engineering, security and operations teams to ensure developers are using the most secure and updated tools available.
For more about the value of internal developer portals, check out this Gartner Tech Insights report. In the meantime, there are multiple tools that seek to bolster security in the app dev process through app-level observability and vulnerability data.
While these tools are necessary, they should be included in the app platform and more importantly provide data that is actionable, as highlighted in this KubeCon talk by Kara Yimoyines.
And if the idea of platform engineering is new to you, check out this white paper about how to build a platform that will actually help your developers deliver quality software faster.
Read more about the DevSecOps definition and the benefits of DevSecOps.
