Don’t Shift Security Left; Integrate It Everywhere
Software development as a discipline is inherently heuristic. This makes it occasionally susceptible to social and management organization trends.
Practices such as DevOps, agile and test-driven development have permeated across startups and enterprises — as have other technical advancements — including cloud native computing, event-driven architectures and full-stack observability. These practices are intended to increase software reliability and reduce toil on developers, though achieving this comes with trade-offs.
Security is a perennial consideration, and maintaining a proscribed enterprise security posture can be at odds with creating a frictionless application development and delivery process. However, it doesn’t have to be this way. Security must be considered an integrated and continuous component of the app development and delivery process.
In a recent conversation with VMware, our team at CCS Insight explored the idea of shifting security left and why it often fails. As enterprise organizations embrace modern app dev practices, they must foster an environment that reduces friction in the application development and delivery process.
Insecure Code Precedes Secure Code (and It Should)
Issues in software typically fall into one of two categories: functionality or security. For net-new applications, developing features and eliminating bugs takes precedence over making those features secure. Understandably, most organizations incentivize measurable milestones like feature development at the expense of invisible attributes (such as the absence of vulnerabilities). The issue is role-based: Developers are fundamentally not security people; the development workflow is a poor fit for security validation and verification.
To draw a parallel, writing code is functionally identical to writing prose — maxims that apply to the former are applicable to the latter. As a representative example:
“Bad writing precedes good writing. This is an infallible rule, so don’t waste time trying to avoid bad writing. (That just slows down the process.) Anything committed to paper can be changed. The idea is to start, and then go from there.” —Janet Hulstrand
Burdening software developers with the task of producing code that is secure from the start is as much a folly as burdening writers with producing prose that is good in the first draft. In the same way that bad writing can be fixed through revision and editing, insecure code can be made secure through testing, revision and validation — software development, like writing, is an iterative process. This is best achieved by testing code early in the development process to find vulnerabilities and reduce toil on programmers by patching these vulnerabilities early in the process, rather than requiring major rewrites or significant design changes nearer the end of a project. Likewise, limiting the scope of net-new projects to a targeted set of objectives — otherwise known as a minimum viable product — aids in reducing surprises after shipping.
Shifting Security Left Requires Collaboration and Motivation
Writing code is only one aspect of application development, even if it is the primary criteria by which individual programmers are evaluated today. Effectively shifting left for security requires consideration for people management and workload management. Adding responsibilities for security testing without allotting time for those responsibilities to be carried out will result in minimal effort put forth. Developers will perceive it as “not their job” if there is neither benefit nor evaluation for this (or, practically any) task.
Shifting security left is not a simple matter of moving responsibilities from operations teams to development teams. It is about making it so developers can write secure code without interrupting their flow. Investing in automation, including validated common platforms that support golden paths, not only fosters a shift-left security culture, it can reduce duplicated efforts in application life cycle management.
This motion also requires some level of upskilling, as developers might not be aware of the full catalog of services in any one cloud, or the best practices or security posture for implementing a particular service on a given cloud platform. Collaboration with platform engineering about available options is likewise beneficial. Among cloud practitioners in CCS Insight’s IT Infrastructure & Software Survey for Financial Services & Insurance, security was cited as the most influential factor in determining where workloads should be placed.
Practical Considerations for Continuous, Integrated Security
Deploying an application is as much of an assessment of that software as it is an assessment of the underlying environment in which an application runs. Creating, testing and validating an environment using Infrastructure as Code (IaC) tools, which can be shared across teams and reused in development and production systems, can significantly reduce the amount of toil developers contend with on each project, eliminating the need to reinvent and retest environments for each platform, environment or workload.
Integrating automation into development platforms is a shortcut to this, providing automated remediation, preconfigured templates, container image builders and image signing inside the interfaces developers are already familiar with.
From a programming perspective, modernizing applications is an opportunity to reassess both the security practices and implications of an application, as well as assess the provided functionality and practical use of an application.
For applications written in scripted languages, are there hard dependencies that require outdated/insecure interpreter versions, such as Python 2.7 or PHP 7? Are libraries used in the program up to date, and are those libraries actively maintained? What about the provenance of those libraries? From the package manager to the package maintainer, could you potentially be at risk for a repeat of the left-pad incident?
More generally, is there input validation? Is the application environment end-to-end encrypted, and is that encryption itself implemented sensibly? Is there role-based access control (RBAC), and from where are role definitions and user assignments inherited? How frequently is that source checked for out-of-date entries (former employees)?
In terms of functionality and practical use, has the scope of service that the application was deployed to provide changed? If individual features — and, by implication, data — provided by the app are not needed, refactoring the application to reduce functionality decreases the potential attack surface for adversaries to exploit.
These are all attributes that can be measured using observability tools. While various monitoring tools capture logs, metrics and traces, observability tools by contrast assist practitioners in deriving insights from that collected data. These insights can be used to inform application modernization initiatives or for day-to-day operations professionals to monitor application or system performance.
Making Development Utopia a Reality
Tools and practices exist to improve security posture early in the application development or modernization process. Internal development platforms with pre-built app templates and automated container builds support the shift-left paradigm, while Infrastructure as Code tools create validated common environments for running applications. Platform observability tools and application-level observability provide usage and performance insights. However, while these tools are useful, gaining the greatest value from them requires a mindset shift and a development culture that empowers developers and platform engineers to collaborate on the shared goal of improving security outcomes.
Balancing innovation, security and compliance can be challenging. It requires a holistic and integrated approach. For more perspective on the dynamic cloud native security landscape, download “Navigating the Path to Secure Apps,” a report about challenges and mindsets to consider for your application security strategy.
