F5 : Securing Apps starts with Securing the SDLC Pipeline

Modern development practices are increasingly automating the development lifecycle. From IDE to code repositories, from automated build and scan to release into production, the tools are strung together to form a continuous delivery pipeline.

Repositories act as both places to store code and to initiate the events that comprise the delivery process. When code is committed, it may run a security scan. When a configuration is changed, it can be automagically pushed to the appropriate infrastructure for immediate deployment.

These tools are speeding up the development, delivery, and deployment process - and increasingly they are 'in the cloud'. Those that reside on-premises are often accessible via the Internet to support an increasing community of remote developers. While most organizations are security savvy enough to require credentialed access to repositories, what they aren't necessarily doing is securing that access against modern threats.

One of those modern threats is credential stuffing. Generally posed as a risk to corporate resources, the reality is that any credentialed system accessible via the Internet is at risk of being compromised. Developers are no more or less likely than any other IT professional to apply secure password practices. Reuse of passwords across the Internet is common, and the exposure of billions of credentials enables attackers to leverage a rich set of resources in their efforts to gain access to a variety of systems. Consider this article exposing this aphorism: 'A survey of 306 infosec professionals at London's Infosecurity Conference 2018fromLastlineshowed that 45 percent commit one of the biggest security cardinal sins - reusing passwords across accounts.' If nearly half of security professionals are reusing passwords, imagine what the profile of the rest of the IT community - including developers - looks like.

Existentially, the infamous data breach at the U.S. Office of Personnel Management (OPM) that began in 2014 was carried out by attackers who had successfully compromised the credentials of a privileged user. Once the attackers had successfully stolen those credentials, they were able to access not only the sensitive information contained with the OPM's servers but were able to move laterally into servers and infrastructure for the U.S. Department of the Interior where they caused havoc as well.

Access to systems and services that comprise the SDLC allow attackers to poison the well, as it were. Injection of malicious behavior or theft of ideas is easily accomplished if one has access to source code.

To combat this threat, organizations should consider extending the notion of a zero-trust architecture to the tools in their software development pipeline. From the IDE to cloud management consoles to code repositories, using Privileged User Access can enforce strong security practices based on MGA/CAC.

Privileged User Access and the SDLC Pipeline

Privileged User Access (PUA) is basically federation without SAML or the requirement for applications to support some sort of exotic method of authentication. It's able to extend the principles of zero-trust to legacy apps as well as support modern, web-based applications.

This solution is based on the ability of F5 Access Policy Manager (APM) to act as a credential proxy along with its capability to automatically general ephemeral credentials. In a nutshell, users are authenticated against a corporate credential store (domain controller, LDAP) and then APM generates ephemeral credentials that can be used to log in to the protected system. In the case of the development pipeline, this could be the code repository such as Bitbucket, GitHub, or GitLab. This approach keeps a tighter rein over access to the repository without introducing a ton of process overhead for the developer.