#cybersecurity | #comptia | #info | What AppSec Can Learn From Developers’ Feature Bug Workflows


In order to scale application security (AppSec) to meet the pace of the software feature development, AppSec must engage developers with new workflows that balance security and productivity. In order to meet this challenge, today we are announcing new purpose-built security workflows, from which our customers are achieving a 5X reduction in mean-time-to-remediation (MTTR).

The Disconnect between AppSec & Feature Development is Growing

The increase in feature velocity of the modern software development lifecycle (SDLC) is driving a disconnect with AppSec. The SDLC is automated and fast, while AppSec remains manual and slow. In a recent survey, 96% of developers reported that the disconnect between security and development workflows inhibits their productivity. The disconnect is not lost on AppSec professionals who, in the same survey, reported that building developer-friendly workflows is their top priority. Yet, every aspect of security polled had at least 86% of developers agreeing that it inhibited their productivity. It is clear that attempting to stretch traditional AppSec tools that were designed in a different era, for a different purpose and a different user is not working.

With developer to AppSec staffing ratios often in excess of 200-to-1, chronic AppSec talent shortages and burnout, it is clear that scaling to meet the needs of the modern SDLC is not something AppSec can spend or hire its way to. Engaging developers and creating a culture of accountability amongst development teams to secure the code they write in a timely manner is the only way security can match the pace of modern development. Productivity remains the stumbling block, but solving it won’t be one-size-fits-all.

Different tools will still require different processes. For example, tools like static application security testing (SAST) and software composition analysis (SCA) should be considered developer-centric because their value is derived less in how the tool is operated (traditionally by AppSec teams) and more in how the results are handled (by development teams). On the other hand, dynamic application security testing, penetration testing, and web application firewalls should be security-centric because they require deep security expertise to configure and operate effectively.

What Can AppSec Learn From Efficient Feature Bug Workflows?

The modern development workflow is git-based. Developers have become accustomed to immediate feedback loops for feature bugs, such as unit testing, as part of their check-in process. When submitting pull/merge requests, build rules prevent new code that fails unit tests from being accepted into the master branch. Hence, code quality standards are enforced and each developer is accountable for meeting them in the code they write. Specifically, the feature bug workflows are:

  • Liked by developers, who buy-in to it willingly
  • Feedback is immediate & timely
  • Feedback is trusted
  • Feedback is regular & expected
  • Developers never have to leave their environment
  • Developers are accountable for code they write
  • Quality standards are customizable per organization and/or repository
  • Quality standards are enforceable & done so at the right time
  • Developers adapt their coding practices to the standards enforced over time

How Developer Friendly Workflows Reduce Inefficiencies

A developer-friendly workflow should ensure that the right developer gets the right vulnerability information at the right time. In ShiftLeft’s customer base, we’re seeing the results to be dramatic, including a 5X reduction in MTTR. Let’s break each of these goals down.

The Right Developer: On the surface, this sounds easy. However, in practice, traditional AppSec practices of scanning source code after the application has been built (in test or production phases of the SDLC) create unnecessary confusion (and subsequent busy work) about which version the vulnerability was in, which line of code it’s on today and which developer wrote it. You cannot create a culture of security accountability when it’s hard to know who even wrote the code.

The Right Vulnerabilities: This also may sound trivial. Shouldn’t we fix all vulnerabilities? In theory, yes, but in practice, AppSec is about prioritizing risk. Different organizations will have different risk tolerance levels based on the criticality of their data, the business value derived from their apps, and general preferences. This will translate into unique prioritizations based on vulnerability severity and volume. Furthermore, within each organization, applications often have different criticality, such as an informational website versus an e-commerce portal, which should further factor into the prioritization. Codifying which vulnerabilities must be fixed and which can be tolerated is a key aspect of developer-friendly security workflows.

The Right Time: As a best practice, software teams should always remain ready to push the master branch into production. Hence, applications should be considered vulnerable once code gets merged into the master branch. This means the right place to insert security is as a build rule during the pull/merge request. Furthermore, running security tests in the development phase of the SDLC is far more efficient. When developers get immediate vulnerability feedback, they can fix the code while it’s still fresh in their minds, without productivity-killing context switches. Furthermore, when vulnerabilities get fixed before merging into the master branch, no additional code can be written that depends on the vulnerability. Thus, the vulnerabilities that require the most effort to remediate are eliminated. Lastly, when performed regularly and predictably, developers will quickly come to expect security feedback, which means they will adapt their coding practices what the build rules will and will not allow. Regular immediate feedback that is accurate and trusted teaches developers better secure coding practices over time.

Purpose-Built Developer Workflows in ShiftLeft’s NextGen Static Analysis

With our new release of NextGen Static Analysis (NG SAST), we’ve created a security workflow for developers that embodies the above lessons. It’s an automated security feedback loop with every pull request. The experience is similar to unit testing in that developers get immediate and accurate results all without leaving their development environment.

NG SAST security feedback loops occur without the developer having to leave their environment

The Security teams can enforce standards through build rules. The build rules accept or deny new code into the master branch by editing a human-readable text file and can be made in a matter of seconds. Hence, it’s easy to prioritize vulnerabilities based on the needs of each organization or even each code repository.

https://securityboulevard.com/
Leverage easy-to-update, human-readable build rules to accept or deny pull requests

We’re optimistic that our developer workflow will dovetail into most organizations’ existing processes. However, we also know that it’s not one size fits all. As a modern development organization ourselves, ShiftLeft has always built our own services with microservices-based architecture and we eat our own dog food with our APIs. This means that API access and reliability has been a primary design principle. As such, all of the data in our dashboards are available via well-tested APIs for even further customization.

https://securityboulevard.com/
ShiftLeft’s NG SAST was built from day one with robust APIs in mind

For developer-centric tools like SAST and SCA, we naturally think the future is purpose-built products for developers. Being developer-centric isn’t just a workflow. For example, ShiftLeft customers typically increase their scanning frequency by 110X when they automate NG SAST at the pull request. That means unlimited concurrent scanning and the ability to scale computing needs up and down become imperative to avoid bottlenecks and queuing. It also means self-service onboarding, free accounts that are really useable so developers can explore how the service works and pricing that is hassle-free and transparent.

To learn more about ShiftLeft and how NG SAST can increase productivity and security in your organization, please:


What AppSec Can Learn From Developers’ Feature Bug Workflows was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by Andrew Fife. Read the original post at: https://blog.shiftleft.io/what-appsec-can-learn-from-developers-feature-bug-workflows-225676c96518?source=rss—-86a4f941c7da—4



Click here to go to the original author and source to this story.

______________________________________________________________________________________________

Get your CompTIA A+, Network+ White Hat-Hacker, Certified Web Intelligence Analyst and more starting at $35 a month. Click here for more details.

.  .  .  .  .  .  . .  .  .  .  .  .  .  .  .  .   .   .   .    .    .   .   .   .   .   .  .   .   .   .  .  .   .  .

Leave a Reply