With attackers increasingly targeting developer accounts and using them to poison software builds, manipulate code, and access secrets and data, development teams are under pressure to lock down their development environments.
Attackers are targeting the extensive access that a typical developer has to source code, code reviews, code commits, code modification, and other privileged tasks. The attacks on SolarWinds, Codecov, and Kaseya in recent years all demonstrate the havoc that an adversary with access to a development environment can wreak on both the victim organization and its downstream customers.
Several high-profile organizations have begun requiring developers to use some kind of two-factor or multifactor authentication (2FA and MFA) to protect their accounts. However, while authentication can help secure your software development life cycle (SDLC), it's not a comprehensive approach to managing risk in your supply chain.
[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]
Is it time to mandate MFA?
In response to the rise in attacks on the SDLC, GitHub, which constitutes a central component of the software supply chain for many organizations, has begun mandating 2FA for all the 100 million users that submit code to the repository.
In the months since then, the Microsoft-owned organization has been moving users over to MFA in large numbers. Users have the option of using SMS text messages or time-based, single-use passwords as their second authentication factor. Eventually, developers who choose to not use MFA will be locked out of their accounts.
Many other code repositories and organizations have begun requiring the same or have implemented MFA for a while. Examples include Apple and Google, which require MFA for all accounts in a developer program. Earlier this year, Valve, the company behind the popular Steam video game platform, announced plans to require MFA for developers after an attacker compromised a developer's credentials and distributed malware to Steam's users.
Alex Ilgayev, head of security research at Cycode, said organizations need to make 2FA a mandatory requirement for every system in the development process, including code, build, package managers, and cloud.
"In many recent breaches, attackers have managed to grasp developer-privileged access to the system through simple techniques like phishing or compromising developer workstations containing a lot of sensitive information such as tokens and passwords. Requiring developers to use a second authentication factor, in addition to their password, can mitigate most of these risks while also forcing potential adversaries to develop more sophisticated attacks."
—Alex Ilgayev
The use case for MFA in the SDLC
Kyle Hankins, managing principal of application security at Coalfire, said MFA increases the likelihood that a developer accessing data or taking an action is who they say they are.
"Historically, passwords are abysmal at doing so consistently and safely, in part because they tend to be stolen/guessed fairly easily or are hard to remember, which poses its own problems. 2FA can mitigate risk caused by stolen credentials and is useful in any situation where the impact of credentials being used by an attacker would have a significant impact."
—Kyle Hankins
Potential use cases for MFA in the software development lifecycle include making it harder for attackers to use a developer's credentials to make unauthorized code changes, merges, and commits; stealing credentials and secrets; accessing data; pushing unauthorized infrastructure changes; and releasing software into the production environment. Organizations can also use MFA to secure CI/CD consoles, log dashboards, and pipeline definition files, and they can require accounts with privileges to make major pipeline changes.
MFA is not an 'end-all solution'
Scott Gerlach, co-founder and CSO of StackHawk, said it's important to put MFA into perspective. "All software development teams and, frankly, every team within an organization, should be using [MFA] to access the systems they need to do their job."
However, Gerlach said that while implementing MFA helps reduce authentication risk, it is "not an end-all solution."
"You still have to design authorization processes to match the job roles needed. Just because someone can authenticate does not mean they should be automatically authorized to perform actions like approve pull requests or push code to production. Sane processes should be in place to ensure testing, code review, and third-party approvals exist in CI/CD processes."
—Scott Gerlach
Coalfire's Hankins said it's key for development teams to understand that MFA is not solving any core security issue. MFA bolsters the efficacy of existing password and other single-factor authentication mechanisms, but it does not address insider risks.
"If an insider can log in with a password, adding [MFA] doesn’t make it harder for that malicious insider to log in. Where it does help is instances where a user might have their password stolen. In that case, the second factor —unless it is also acquired — would prevent the unauthorized access."
—Kyle Hankins
Tokens to the rescue?
The wide use of security tokens in CI/CD processes is another way to expand authentication, said Cycode's Ilgayev. Organizations use security tokens — such as OpenID Connect (OIDC) tokens and access tokens — as keys for granting developers access to the CI/CD pipelines, infrastructure, and secrets needed to build, test, and deploy applications. The tokens contain information such as the user's permissions and scope of access in the pipeline.
Most security tokens can perform a range of privileged actions and can bypass MFA configured for that system because they are run through automation, Ilgayev said. "For example, I may have 2FA configured for my AWS account, but once I generate service account tokens, I can invoke them anytime and everywhere without the need for additional approval."
In the modern SDLC, CI/CD processes are usually included in the code repositories. This makes it harder to segregate duties and manage authorization for sensitive build processes, Ilgayev said. This gives intruders a potential vector for accessing an organization's production environment via the build system.
"As an example, if I'm using GitHub Actions, the CI is managed in GitHub and can be altered by any developer."
—Alex Ilgayev
A call to action on a comprehensive approach
MFA is also a limited approach because it introduces a certain amount of friction into every login or activity that requires it, Hankins said.
For some tasks, such as commits to production, especially on publicly accessible sites such as GitHub, MFA is a valuable safeguard. But it can be cumbersome in other instances and does not provide a comprehensive approach to manage the associated risk.
"While [MFA] can be effective for denying malicious access to code repositories and build services, it doesn't cover the entire SDLC."
—Alex Ilgayev
Given the privileged access in question and the potential downstream risk exposed by recent attacks, organizations need a separate set of processes to mitigate risk.
Matt Rose, Field CISO at ReversingLabs, said MFA is valuable in helping to ensure that developers are authenticated properly. But adding an additional step to the process of developing code is at odds with the speed and scale in modern DevSecOps environments.
"In order for it to be effective it has to work with the way developers write and commit code and not a new or different process. The last thing anyone wants is another excuse to push back on security teams."
—Matt Rose
