Category: Platform Engineering

  • Why Developer-First is the Future of AppSec

    Why Developer-First is the Future of AppSec

    DevOps culture and rapid cloud adoption mean developers are shipping code faster than ever and, in many cases, security teams struggle to keep up. To avoid relegating security to afterthought status, organizations must shift left and adopt a developer-first approach to application security (AppSec).

    Organizations that depend on software development need a solution that accomplishes two essential things to adapt and survive: Risk-appropriate security measures and an even distribution of functions across the stack. First, risk-appropriate security measures must be applied to all software before it is delivered or deployed. Second, they must adopt processes that enable security functions to be distributed across the development stack in a way that will not slow down the pace of development.

    Just as the entire development process starts with developers, integrating security should also start with a developer-first approach. Developer-first AppSec is the future; here’s how organizations can evaluate tools that will help them adopt a developer-first approach.

    Why Developer-First is the Future

    Developers outnumber application security engineers by as many as 100 to one, and AppSec functions cannot scale if security practitioners are the only ones responsible for security. This imbalance suggests that organizational leaders must better distribute security ownership across the developer teams that own the software asset.

    As it stands today, many companies expect developers to build and deploy software faster than ever before. Security teams often can not keep pace with software development, and they become a roadblock to software delivery. To meet project development deadlines and their key performance indicators (KPIs), developers tend to leave security teams behind. They do not have the time or the incentive to slow down development because application security tools or processes are slow and cannot keep up.

    Security and developers are at cross-purposes in today’s software development model. They are pseudo-adversaries because AppSec teams know what it takes to make code secure, or at least they know how to find vulnerabilities. And, on the other hand, developers need to write code that works well and meets the sprint’s deadline.

    Friction Between Teams

    This growing problem creates friction between these two teams. It’s not that security teams don’t care about the organization’s need to produce quality software quickly or that developers don’t care about security. It’s just that each team is measured and incentivized to achieve opposing objectives. AppSec programs must create a developer-first approach to building software quickly and securely to combat this growing problem.

    It is not feasible for organizational leaders to provide security engineers with the entire business or environmental context behind software applications. In this sense, AppSec teams are working with limited vision. They may not see how the software fits into the organization’s big picture or understand its priorities.

    With limited contextual understanding, security teams necessarily rely on developers to make decisions about acceptable risks. If left to their own devices to view the world through a security-centric lens, AppSec teams could get bogged down—potentially spending too much time enforcing security measures that do not apply to the task at hand.

    Since developers are building the software and know what the services are designed to do, security engineers must defer to a developer-first approach so that decisions about security issues will align with the business context and acceptable levels of risk.

    Finding a Developer-First AppSec Platform

    Below is a condensed guide to help organization leaders evaluate potential AppSec platforms. These questions will help identify a solution that will enable the organization to build a developer-first security program.

    • Will the solution flood the developers and AppSec team with more and more results, or will this help them fix the essential gaps?
    • Will the solution provide context to help developers focus their limited time on security work that matters, or will it end up wasting time on things that may not even present a risk?
    • Will the solution help build security measures as guardrails to prevent security issues in the first place?
    • Is the solution flexible enough to enable building custom application security checks and policies in the SDLC?
    • Does the solution provide flexible ways of communicating actionable security information directly to developers in real-time within dev tools like source control systems, CI/CD platforms or engineering task management systems?

    There are an overwhelming number of application security solutions on the market today, most of which are designed to create security alerts about every conceivable threat regardless of the business context of the software being developed. More tools are then needed to manage the identified vulnerabilities.

    What This Future Will Look Like

    AppSec teams must recast themselves as security facilitators providing expertise for solving complex challenges and maintaining oversight of the developer teams’ security efforts. Developers should own tactical security tasks, but the AppSec team should continue to be the experts in making risk-based decisions and driving security accountability across the business.

    Inside many organizations, application security is only beginning to become integrated into developer workflows. This integration creates both opportunities and challenges. As organizations strive to make AppSec an enabler that aids developers in creating secure software quickly, developer-first AppSec programs let businesses make their digital transformation journey safer and faster.

  • Bridging the Developer Experience (DevX) Gap

    Bridging the Developer Experience (DevX) Gap

    They say our past experiences have an impact on how we view life and our general outlook. Routine behaviours and patterns become a program that we follow day in, day out. We stop using our minds to their fullest potential and become trapped in unquestioning, continual cycles of process and emotion.

    The same could be said of our experiences in the present—our worlds shaped by the environments around us. The people, practices, tools and culture. Only by challenging these accepted patterns can we start to think about changing our mindsets.

    DevOps is a mindset; a way of forming an agile relationship between development and operations teams to speed up delivery of software to support business operations and improve customer experience. By and large, it has been successful. Companies react to change more effectively; software is developed and deployed swiftly. It has become a necessity across most organizations.

    There are challenges, as we all know, however. The State of DevOps Report 2021 found that 83% of organizations are implementing DevOps practices, but most are still failing to scale adoption. It’s a situation that hasn’t changed for four years. Why? Among other things, the report states there are too many silos, not enough skilled people, a saturated market with too many tools—and a culture that prohibits scale.

    Given that the end goal of DevOps is to generate untrammelled innovation across an organization, getting the culture right is critical. Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

    Above all, it’s about creating the best possible developer experience (DevX) in which to thrive.

    The Developer Experience Gap

    Stephen O’Grady at Red Monk, the developer-focused analyst firm, originally wrote about a DevX (developer experience) gap in this post back in October 2020.

    Stephen likened the experience you get from an iPhone to the expectations of developers. The iPhone’s closed SDK created an environment that allows all developers to work in a consistent way. Functions are tightly integrated so that, for example, it would be easy to ensure the music volume lowers when you receive a call. A basic function, but one that we expect to work seamlessly with any app we install.

    Since then, developers have been served a vast array of tools and services with more and more software arriving on a daily basis. The challenge is that, where the phone and music player teams were controlled in a way that would make them work well together, modern development infrastructure doesn’t have that capability. In most cases, the toolchain is a “patchwork quilt” of products and services from different suppliers. And it is up to developers to build and maintain that quilt.

    This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

    In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

    Delivering the DevX Factor

    Attracting the best people is about showing that the experience they will have in your organization is both rewarding and liberating, so expecting developers to spend the bulk of their time not developing is clearly not an optimal experience. Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

    Where to start? Well, contrary to popular belief, you don’t need an army of DevOps engineers to reach your goals. Instead, you need to empower your existing teams to reach their full DevOps potential, supporting their progress with the right tools and training for their experience and role.

    As with any work culture (remote or hybrid), the importance of knowing where to find what you need and how to collaborate with other teams has never been so important. Tooling is a good place to start. DevX is affected by the tools they use, so organizing them in a way that helps with the culture is a step forward. In a multi-cloud, multi-vendor environment, there isn’t going to be one tool that does it all so the key is to allow teams to use the tools they love and automate as much as possible to remove the repetitive tasks.

    Automation is also a critical element in the race to reduce time-to-market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on developers. Having access to testing automation in a consistent way will improve the overall experience for DevOps teams.

    And finally, think about starting your DevX journey by using a self-service platform, where information, tooling and automation can be centralized and made available to developers on demand. For overworked specialists, access to a platform that connects to any tool and creates an on demand environment that automates much of the repetitive work will create more time for them to do what they were originally employed to do: Develop.