The growing need for a secure software development lifecycle has prompted a discussion around the concept of “shift left.” Security has been treated at the end of the development cycle for decades, and software development has been mostly linearly planned. As cloud-native applications evolve and users demand real-time and 24/7 software services, scheduling security and testing at the end of the development cycle can create significant development, operational, and cost implications.
In a shift-left approach, organizations take a wider view and focus on security from the beginning of the development lifecycle, starting when the first line of code is written and running throughout the entire process to when applications are running in production.
A new shift-left security mindset is required in which security is considered an infrastructure element, just like networking and storage. However, unlike networking and storage, where a lapse means downtime of applications and attendant losses, a breach in security can result in the loss of sensitive information that can be much more costly and, in many cases, irretrievable.
Take a Holistic View of Security
Enterprise security covers many aspects, including securing corporate assets, equipment, tools, documents, and other internal information. As organizations undergo digital transformation, they rely on software to deliver the agility, performance, and scalability benefits they seek. But what does it take to securely run a software application in a production environment?
If an enterprise is looking to improve its security posture, it needs to invest heavily in its processes, people, and products. Improvements in just one of these areas might not improve the overall security posture, and shortcomings can lead to an overall software security risk, which is why these investments should go hand in hand.
For example, if security teams cannot communicate effectively and collaborate with development and operations teams, it will only be a matter of time before attackers can discover security vulnerabilities.
Business Agility Through Kubernetes
Modern applications are based on cloud-native technology and microservices architectures. Containers have become the default way to package microservices because they provide consistency, portability, and repeatability.
As more organizations move to cloud-native applications, Kubernetes has become the de facto container orchestrator, making deploying, discovering, and scaling these microservices easy.
Kubernetes and containers can provide greater business agility, including the ability to more quickly move new code into production. At the same time, however, Kubernetes makes it more challenging to secure environments. Although Kubernetes uses familiar concepts such as authZ & authN, certificate, and encryption, it introduces new concepts such as deployment, pods, ingress, namespaces, role-based access control, service accounts, secrets, network policy, resource limits, and quota. Mastering these concepts can be a steep learning curve, not only for developers and operation teams, but for security teams as well.
The Pros and Cons of DevSecOps
Kubernetes breaks down the boundaries between DevOps and security teams, which has transformed DevOps into DevSecOps and driven security towards a shift-left approach. Although DevSecOps can optimize the DevOps practice and reduce software development cycles to weeks or even days, many organizations are discovering the challenges of adopting DevSecOps when trying to secure their Kubernetes environment in production.
DevSecOps and the concept of shift left require higher levels of security knowledge on the part of developers, who also need to manage the design, development, architecture, infrastructure, and testing of applications. The additional security duties can put more pressure on DevOps teams already under pressure
in their effort to deal with Kubernetes issues.
A Realistic Approach to Shift-Left Practices
Requiring developers to be security experts in addition to all their other duties is in most instances an unrealistic expectation. An organization’s best option is to adopt tools and technologies that are secure by default and have security experts as part of the platform team who can understand the security structure and build guardrails and apply security best practices to that platform.
In addition, organizations can institute the use of the Software Bill of Materials (SBOM). Like a detailed menu of materials, SBOM lists open-source and third-party components in the code base, helping teams to better understand the relationship between individual projects and specific code in the development cycle.
SBOM also contains component license information, which can help companies understand license and regulation information, making it easier to automate compliance checks. Detailed software documentation also improves the efficiency of code reviews by developers and security teams, reducing the burden on developers.
Security Mastery Step by Step
Implementing a shift-left security regimen doesn’t have to happen all at once. It can be a journey that slowly increases an organization’s security posture as its platform team gains the confidence to run a secure production environment.
The journey can start with securing access and network traffic from outside a cluster (north-south traffic), then securing access and network traffic from inside the cluster (east-west traffic), followed by applying security best practices.
The team can then focus on achieving security compliance, building a zero-trust architecture
, and improving supply chain security. Each phase will require training, including learning how to deploy and manage Kubernetes. Success will depend largely on how quickly a team can achieve these capabilities. However, breaking the process down and proceeding in this way will enable organizations to improve their security practices and provide better security protection for the organization.