devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

DevOps World 2022: Using SBOMs to Secure the Software Supply Chain

As supply chain attacks become increasingly prevalent, visibility is emerging as a necessity in cybersecurity. One way to improve visibility and secure your software supply chain is with a software bill of materials (SBOM).

An SBOM is a list of all the components within a codebase. By providing insight into open source and third-party components, SBOMs improve overall visibility and are integral to the identification of security or license threats. To properly secure the software supply chain, organizations must have an understanding of all the components in their applications; it is especially important to do so with containerized applications and those built using cloud-native, microservices-based architectures. That’s why SBOMs are becoming a cornerstone of a comprehensive application security strategy.

The Need for Visibility

Gartner’s recent report Innovation Insight for SBOMs emphasizes the need for constant visibility into the software development life cycle and how SBOMs can help organizations and developers achieve that goal. While Gartner recognizes that open source software is a foundational component of modern software development, it also noted that it can be a major contributing factor in software vulnerabilities.

“While reusable components and open source software have simplified software development, this simplicity has exposed a critical visibility gap: Organizations are unable to accurately record and summarize the massive volume of software they produce, consume and operate,” the report said. “Without this visibility, software supply chains are vulnerable to the security and licensing compliance risks associated with software components.”

To mitigate the associated risks, Gartner’s report not only emphasizes the importance of SBOMs but the need to automate the SBOM creation and validation process. To achieve supply chain security at scale, organizations should automatically generate and verify SBOMs and use that data to constantly evaluate oncoming risks.

This ties directly into the continuous integration and continuous deployment (CI/CD) process, which uses SBOM data and assessments to ensure threats don’t slip under the radar and wreak havoc. You can more easily identify security vulnerabilities at any stage in the pipeline and remove them—because an SBOM gives you more granular visibility.

The importance of SBOMs has even been noted by the U.S. federal government. As stated in president Biden’s Cybersecurity Executive Order 14028, any company that sells software to the federal government will be mandated to provide a complete SBOM.

The initiative has also spread to other branches of the government, with the Cybersecurity and Infrastructure Security Agency also emphasizing the significance of SBOMs.

“CISA will advance the SBOM work by facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases,” said CISA in a statement on its website.

SBOM Requirements

The U.S. Department of Commerce and the National Telecommunications and Information Administration (NTIA) have outlined the minimum elements required. For one, data fields with baseline information about each component are required. Also, automation support is needed, as SBOMs necessitate machine readability for support at scale. Finally, the need for practices and processes was outlined, calling for frequent SBOM generation, including transitive dependencies and widespread availability of this information to those who need it.

On many fronts, SBOMs have become non-negotiable throughout the software industry. In order to effectively detect and respond to threats, organizations must take preemptive steps to ensure visibility is maximized, and SBOMs accomplish just that.

Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

September 8, 2022
How’s Facebook Work? They Don’t Know! | Cali. Pay Law | NASA RISC-V Launch

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Facebook engineers admit they’ve no idea what Meta stores (or where), California requires job ads quote salaries, and RISC-V will power future NASA spacecraft. (more…)

September 8, 2022
Playwright: A Modern, Open Source Approach to End-To-End Testing

I was excited when I started writing my first end-to-end tests years ago. The idea was promising; create an automated test suite that spins up a browser and mimics your user’s behavior. Test your website end-to-end. Frontend, backend, your database—you name it. All these automated tests would cover everything! Unfortunately, it wasn’t all roses and sunshine. The implementation was more complicated than expected and the results were not as stable as I had hoped. On one hand, I expected that learning a new testing framework would take time. But on the other hand, investing time and money just to end up with flaky tests and countless false positive alerts was not acceptable.

Luckily, testing frameworks evolved, and new libraries make end-to-end testing more approachable and, most importantly, less flaky. One of the more recent solutions is Playwright. Let me tell you more about it!

Write Your Test Code in Four Different Languages

While Playwright’s default choice is Node.js, it offers support for three other languages: Java, .NET and Python. You’re in good hands if your team uses one of these languages because no one wants to learn a new language just to write some tests, right?

Cross-Browser Tests on the Back of the Chrome DevTools Protocol

Contrary to other solutions, Playwright doesn’t use the WebDriver protocol. It leverages the Chrome DevTools protocol to communicate with Chromium browsers (Chrome/Edge) directly. This approach allows for more direct and quicker communication. Your tests will be more powerful and less flaky.

But Playwright doesn’t stop at Chromium browsers. The team behind the project understood that cross-browser tests are essential for an end-to-end testing solution. They’re heavily invested in providing a seamless experience for Safari and Firefox, as well, and even Android WebView compatibility is in the works.

Testing your sites in Chrome, Edge, Firefox and Safari is only a configuration matter. And this saves time and headaches!

Fast Tests Due to Auto-Waiting

It’s not only about automating multiple browsers, though. If your tests are hard to write because you have to place countless “sleep” statements everywhere, your test suite will take hours to complete and become a burden.

To avoid unnecessary waits, Playwright comes with “auto-waiting.” The idea is simple: Instead of figuring out when a button is clickable by yourself, Playwright performs actionability tests for you.

Let’s look at an example:

“`
await page.click(‘[data-test=cta]’)
“`

There’s nothing fancy about clicking a button, right? Except in Playwright, there is. This innocent “click” call includes additional convenience functionality. When you call “click,” the framework checks and waits for a matching DOM element to be:

– attached to the DOM
– visible
– stable (it’s not animating or moving)
– able to receive events (not hidden or obscured by other elements)
– enabled

All these checks guarantee that your target element is ready to roll when you want to interact with it and, more importantly, it’s clicked as quickly as possible. Don’t worry about DOM elements. Just interact with them and let Playwright figure out the rest—no more wait statements!

Auto-waiting is built into all of Playwright’s interaction methods so that you don’t slow down your test suite. Your tests will be easier to write and run as quickly as possible.

But that’s not all! While I use Playwright via the command line, it also comes with handy tools to make end-to-end testing easier.

Valuable Tools to Create, Debug and Analyze

Playwright provides additional commands and visual tools to make the writing of end-to-end tests as accessible as possible.

Record Scripts With Codegen

To give you a head start with your first test, use Playwright’s test generator.

“`
npx playwright codegen playwright.dev
“`

Only a single CLI command is necessary to spin up two new windows: An interactive browser and the Playwright Inspector. The fun part is that every interaction in the browser window will be recorded and shown in the inspector.

If you want to create a Playwright test that navigates somewhere, clicks a button and fills out a form, these tools are perfect for creating an initial setup.

Replay the generated script, adjust your selectors and assertions, and you’re good to go!

Congratulations! You just created your first end-to-end test, and I bet it didn’t take you more than a few minutes to get there.

Debug Your Scripts While Running Them

When your test suite grows, you’ll find yourself in situations where you must debug complex scripts. For these cases, Playwright provides a handy debug view.

Enable debug mode by explicitly calling `test –debug` or defining the environment variable `PWDEBUG=1`.

“`
npx playwright test –debug
PWDEBUG=1 npm run test
“`

Playwright then opens a browser and the inspector walks you through your test case, similar to your editor’s debugger. Additionally, it highlights the touched elements with a little red circle so you can see what was clicked or filled.

This approach is perfect for debugging tests during local development. But what about debugging failed tests that run in CI or on a different machine? There’s a solution for that, too!

Analyze and Debug Previously Failed Tests

In an ideal scenario, you’ll run your tests automatically on commit or deployment in your CI/CD pipeline. But debugging failed tests from a different environment can be a massive challenge.

Luckily, the Playwright framework allows you to enable a trace mode. Trace mode records all script actions while screenshotting and keeping the website’s state.

Then, if your tests fail on your remote servers, use the provided Playwright tooling to load a generated `trace.zip` file and inspect the test to find out what failed. Method calls, a timeline and screenshots will be available—it’s time travel debugging at your service!

A Refreshing Approach to Synthetic Monitoring and Testing

These are only a few things that make Playwright my testing framework of choice today and the team behind it develops fast and ships new releases every month.

If you want to learn more about the Playwright framework or to chat with the maintainers, there’s a very active community Slack channel with many friendly people.

So, do you still avoid end-to-end tests because they used to be slow and flaky? I hope that I could convince you to give it another try. Because there’s nothing better than knowing that you didn’t break things while developing and shipping software.

September 8, 2022
Supply Chain Security: Has the Next SolarWinds Already Happened?

More than two years after the now-infamous hack of the firm SolarWinds, the incident is very much in the foreground of conversations about cybersecurity defense, threat detection and incident response. As evidence of that: The SolarWinds incident was the subject of five separate talks and panels at the recent RSA conference in San Francisco. Dozens more talks addressed issues related to supply chain security that–directly or indirectly–invoked the SolarWinds incident.

That’s because the SolarWinds attack raises important—if not existential—questions for both software development and DevOps teams and the companies running the software. First: If sophisticated cybercriminals can insert malicious backdoors directly into application code from reputable developers, what organization can afford to blindly trust software? Second: If it is now the responsibility of software teams to spot sophisticated, methodical compromises of their development pipelines, what is the best and most reliable means of doing that? Finally, if it is also now the job of software consumers to monitor for—and detect—compromised binaries from otherwise reputable vendors (like SolarWinds), how should they go about doing that given ongoing staffing and technology constraints?

The answers to these questions are matters of debate within DevOps, software development and information security communities. What is beyond debate is that the SolarWinds incident was not a fluke. In the months since that attack, attackers—both criminal and nation-state-backed—have leveraged software supply chain security blindspots to target development organizations as means of gaining access to sensitive IT environments. While we haven’t yet heard of another incident of the scale or importance of SolarWinds, it is entirely reasonable to assume that the next SolarWinds-caliber compromise could already be unfolding, but has yet to be discovered and/or publicly acknowledged.

Software Supply Chain Security Weaknesses

SunBurst, the malicious implant in SolarWinds software, endures as a topic of interest and conversation for information security professionals and for DevOps and development organizations precisely because of the ways it exposed glaring weaknesses in the security of development organizations and software supply chains. As noted in my analysis of the hack in December 2020 and FireEye’s analysis of the same compromise, the SolarWinds hackers gained access to the company’s development environment months before they actually launched their attack. During that time, they closely studied the underlying source code and mimicked SolarWinds style and nomenclature as they added malicious code and integrated it into the SolarWinds Orion application via a compromise of the company’s build system.

Though carefully planned and conducted, the SolarWinds attack wasn’t foolproof. The attackers left clues, such as their additions of native Windows functions, use of cryptography, compression and more. The attackers obfuscated these using compression and Base64 encoding designed to fool simple threat hunting rules that looked for their plaintext variants and other suspicious strings. Still, the obfuscation repeated throughout the implanted code was enough to send up a red flag to anyone who bothered to look closely. That left the attack open to discovery.

The problem is this: Very few software publishers have the staff, expertise or tooling to comb through massive codebases to spot a handful of sketchy obfuscated strings or analyze large binaries for deviant behaviors before deploying them. As evidence of this, ReversingLabs sponsored a survey of more than 300 IT professionals at software-driven enterprises. It found that 87% were aware that software tampering, like what occurred in the SolarWinds attack, could lead to enterprise security breaches. About 40% of those surveyed said CI/CD toolchain exposures posed a risk to their organization. Still, barely a third of respondents (37%) said they had the means to detect such software-tampering attacks.

Threats to Software Development Organizations Grow

Attackers are aware of this weakness within the software development pipeline, which is why threats to development organizations are metastasizing. Just in the last year alone, we have seen a series of attacks on development infrastructure and software supply chains. In one April 2021 incident, attackers were successful in pushing malicious, unreviewed code directly to the PHP main branch, ultimately resulting in a compromised, formal version of PHP being pushed to all PHP websites. That same month, there was a breach at the firm CodeCov, which involved unauthorized access to and modifications of the company’s Bash Uploader script. An investigation of that incident ultimately concluded that the alteration of a single line of code in that script by an unauthorized third party enabled the attackers to (potentially) export information stored in the users’ continuous integration (CI) environments.

More recently, ReversingLabs observed proof-of-concept and “white hat” activities testing so-called “dependency confusion” attacks, in which attackers set up malicious packages in public repositories like GitHub that squat on the names of private, non-public repositories and sport high version numbers. Misconfigurations in package management systems can result in these malicious components being imported in lieu of the legitimate, privately managed namesakes. As ReversingLabs found, a number of malicious modules discovered on the npm platform were used to target German technology, manufacturing and entertainment firms. It was later revealed to be the work of a white hat firm conducting red team exercises on behalf of those firms. Red team exercises aside, RversingLabs research also detected other, malicious packages in npm, as well as similar attacks targeting Ruby Gems and Python Package Index (PyPi).

And that doesn’t even count issues like the Travis CI flaw that exposed (potentially) millions of credentials to developers’ accounts on GitHub, Amazon Web Services and Docker Hub. Lapses like that can fuel supply chain attacks, giving malign actors the ability to insert malicious code into otherwise legitimate open source or proprietary code repositories. After reading such headlines, and without the means to check code intent, how can developers trust their software to update? And how can they do so while at the same time being forced to frequently update their dependencies to reduce or eliminate critical software vulnerabilities?

Dev Teams Need New Tools

For software development organizations struggling to meet delivery deadlines and satisfy customer expectations, reorienting to address amorphous software supply chain threats and attacks is a bridge too far. The same is true for enterprises struggling to staff security teams and simply keep on top of targeted phishing attacks or threats to public-facing IT assets. Too often, these entities only find religion about software supply chain attacks after they have occurred.

What software development organizations need is a way to secure the CI/CD pipelines and release packages, ensuring that their software builds are free of code tampering and other supply chain risks introduced through build systems. That should include the ability to detect compromises by monitoring for malicious software changes and enforcing security controls and failure conditions on software build processes to ensure that you can release your code with confidence.

On the customer end, organizations need a way to detect malicious behaviors and unauthorized software changes in compiled binaries before they are released into production, while also monitoring for risks like exposed secrets or exploitable software vulnerabilities that might lurk in compiled code.

September 2, 2022
Agile Sucks (Redux) | Plus: DevOps on Mars

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Agile is bad, but “Wagile” is worse.
Plus: This prod is even worse than yours. (more…)

August 18, 2022
Avoiding Security Review Delays

In the summer of 2021, I had lunch with a senior security developer at one of Seattle’s leading tech firms. Even though we were relaxed in the sunny and cool afternoon of the Pacific Northwest, there was no doubt my friend was frustrated. Part of his job was running code through a popular scanning product and then evaluating the results. It was a tough role because he sat outside the team that was developing the code and he was often under pressure to run his analysis within the constraints of their deadlines.

All too often, he had to deliver the bad news that the scan had found security issues. But that alone wasn’t why he was frustrated. His issue was that the tool that he was using was taking several hours to complete scans. He’d taken to starting the scan at the end of the week and hoping that it would be complete by Monday morning. The very tool that was supposed to make his job easier was actually a headache.

This is one of the fundamental challenges of analyzing software systems for security vulnerabilities. All too often, developers and stakeholders focus their project timelines on the functional specifications. Teams work feverishly to rapidly iterate from prototype to finished product.

Security concerns are never disregarded, but the culture of “Let’s see if we can get it working the way we want first and button it up later” ends up costing more in the long run because the evaluating and testing cycles take longer. Not to mention that if substantial security problems are found, it can be difficult to remediate them without breaking things that were supposed to already have been completed. This problem is becoming acute in the SaaS world where solutions are being built faster than ever before with little to no security oversight.

The Right Tools and Software Are Critical

First, managers and executives need to mandate that the entire software development lifecycle and every environment should have security. Particularly for web-based SaaS tools, any vulnerability that exists is a potential attack vector. Attackers know that going after a dev version might not yield a jackpot, but it might give them access that exposes credentials that work in later versions or identifies a vulnerability that flies under the radar into production.

Second, automation and tooling are simply the name of the game. Using tools with code repositories, pipeline management and testing frameworks help ensure the elimination of as many potential vectors of error as possible. Security checks should be the same. We can’t always rely on the skills of a developer or an administrator to follow security best practices.

We need tools that provide reliable and rigorous checks. Moreover, these tools need to run frequently. SAST scanning should be fast enough that a developer can run it with every save, or at least every commit. Coupling SAST and IAST scanning together is the gold standard for secure development. Every time code is compiled into a dev or test environment, it should be tested to make sure that vulnerabilities haven’t crept in and that the permissions and architecture of the system don’t work at cross purposes to expose vulnerabilities.

Finally, there is a fundamental issue that must be addressed in every manager’s office. Code quality is not the same as security. Sure, there might be some overlap, but it doesn’t make sense to have 200 rules for code quality and 50 for security. The two things are not equal, and it’s a fallacy to expect that having high-quality code without frequent security checks will ultimately lead to less time spent in security review. Don’t miss the forest for the trees. Make sure security is the team’s top priority.

Advocating for Security in SaaS

My friend didn’t have a problem holding teams accountable for the code they’d written. In fact, he relished being able to insist on high standards and was proud that his organization empowered him to do so. That’s exactly what we need in the software industry: Individuals who are unafraid to demand the best from their peers. But it’s imperative that we provide effective tools they can rely on to succeed.

The problem of security testing delays are not new to software development. It has been well-documented that it can take 640x the money to fix bugs in production, but due to a lack of effective tools this problem has been amplified in SaaS development. A SaaS development environment presents unique challenges that cannot be met by just employing code analysis or configuration testing for SSPM vendors. It requires a holistic view of the environment and the ability to use customization to be effective in the identification and remediation of vulnerabilities.

With a comprehensive view, those responsible for security and those implementing it will see security as a necessity to innovate quickly rather than a necessary evil that is put off until last in hopes it can be avoided. Maybe then my friend won’t be as frustrated next time we meet.

August 16, 2022
Cycode Expands Scope of AppDev Security Platform

At the Black Hat USA 2022 conference, Cycode this week announced it has added static application security testing (SAST) and container scanning capabilities to its software composition analysis (SCA) platform that is based on a graph database.

Amnon Even-Zohar, director of product management for Cycode, said the addition of these tools brings to eight the total number of modules that are now integrated with its Knowledge Graph database. Those modules address application security requirements spanning everything from infrastructure-as-code misconfigurations and DevOps pipelines to binary and source code analytics in a way that reduces both the number of false positives being surfaced, he added.

That approach makes it possible to provide more context to software remediation efforts by pulling data from across the entire software development life cycle rather than focusing solely on vulnerabilities found in source code, he noted. Cycode, for example, can pinpoint where vulnerable dependencies are found in test and production environments, said Even-Zohar.

A Cycode Pipeline Composition Analysis tool also provides insights into which components enable a vulnerability or security issue, how pipeline components relate to each other and if they are present in runtime environments, he added.

While there’s a lot of interest in implementing DevSecOps best practices in the wake of a series of high-profile AppSec breaches, many organizations still lack the tools required to secure an application development environment on an end-to-end basis. The Cycode platform leverages the data that already exists in DevOps workflows to enable organizations to better prioritize their remediation efforts and lower the total cost of doing so, said Even-Zohar.

The goal is to not only enable organizations to shift cybersecurity further left toward developers but also further right by more closely integrating cybersecurity and DevOps teams, he noted.

The DevSecOps challenge that most organizations are trying to navigate is that, historically, a list of vulnerabilities discovered by cybersecurity researchers is shared with DevOps teams without much context. Developers don’t know which vulnerabilities are most critical or, for that matter, whether the vulnerability identified is actually present within their application environment. SCA tools, in theory, could make it easier to identify, for example, where a Log4j or a shell vulnerability might be found. Graph-based tools take that capability to the next level by making it easier to visualize where any instance of a vulnerability might be found. In the absence of such tools, IT organizations would spend weeks looking for each instance of a vulnerability.

It may be a while before DevSecOps workflows become commonplace but at the very least there is now more awareness of software supply chain security issues. The Biden administration has also issued an executive order that requires federal agencies to review the security of software supply chains. Many enterprise IT organizations are now following suit. One way or another, application security is going to improve. The only thing that remains to be determined is what impact those improvements will have on the rate at which software can be built and deployed.

August 11, 2022
Why You Should Rip Up Your Org Chart and Reorganize Around Value Streams
To compete in the digital economy, teams must optimize both efficiency and effectiveness–it’s a tough ask. The traditional dominator hierarchy is a problem because organizations that use command and control create silos and handoffs that stifle innovation at the team level. Coordinated autonomy releases the creative spirit of individuals–but how can leaders assure alignment with their vision?

One way to eliminate the delays and waste associated with silos and foster autonomy is to arrange around value streams. A value stream is anything that has a customer or anything that delivers a product or a service. All value streams begin with ideas and end when a change is delivered. Or, even better, when our cherished customers realize the intended value outcome. The original intent of Agile was to provide “value” to our customers faster … but we hardly ever talk about what this value is or measure its existence.

Traditional organizational charts arrange resources according to expertise. This means that work is handed off to different teams as it progresses through the value stream. Value streams exist whether or not people call them that and whether or not they actively manage them. Every time a hand-off occurs, it creates an opportunity for delays or errors. It also means it’s hard for people to understand the end-to-end system. Instead, they do as they are told to optimize their piece of the puzzle without really understanding how their actions impact work that’s upstream or downstream.

More progressive ways of working, like Agile and DevOps, do promote cross-functional, autonomous teams, but they typically leave a big gap between planning and delivery and are not always smart at connecting feedback from customer experience back into planning. Value stream orientation promotes team diversity by recognizing the individual background (cross-functionally) into the value delivered to the customer.

Organizing around value streams is the foundation for nurturing the value stream-centric ways of thinking and working that drive both efficiency and effectiveness. Then, customer experience is improved and higher levels of organizational performance are achieved. This is because:
- Putting customer experience front and center brings higher retention and referral rates
- Elevating the concept of flow (see below) gives teams permission to prioritize removing waste
- Balancing innovation with improvements reduces technical debt, toil and unplanned work so employee experience is better, too
- Connecting planning to delivery to feedback in a continuous loop aligns teams and helps with decision-making
Flow is about how fast ideas can move through a value stream and be made available to the people they’re designed for. It’s about outputs and efficiency. Customer experience tells teams about the outcomes of their work and their effectiveness. Used together, these measures ensure the teams are doing the right things right and moving in the right direction.

In this model, leaders share their authority and empower their teams. They support teams’ self-discovery of improvements and make sure those local learnings go global. They help their teams understand how much time they spend innovating compared to reacting or improving. Then the leaders can help their teams reduce distracting and stressful unplanned work and instead invest in increasing capacity for innovation in the future.

Follow these steps to become a value stream-centric organization:
1. Identify your value streams
2. Identify who is involved in each step of your value stream
3. Make your value stream visible by visually collaborating with your value stream team
4. Use tooling to gather value stream data and generate insights for your team
5. Meet regularly to inspect and adapt your value stream
All organizations are composed of value streams, regardless of whether they have been made visible, and most large organizations have complex networks of interconnecting value streams. These dependencies are not easily decoupled. They’re not easily visible, either. But once you’ve mapped them, you can start seeing where they connect and manage the dependencies. Ultimately the goal is to break these dependencies since they cause delays and risk, but it’s hard to do that when they can’t be seen.

Connecting the organizational vision with the value streams becomes much easier with this model. Organizational structures are flattened. Leaders understand which value streams they are accountable for and how they work. The time between having an idea and getting feedback on how it’s received is shorter and amplified. They can see the work being done, measure what impact it’s having and make better decisions about what to innovate or invest in next.
August 11, 2022
What GitHub’s 2FA Mandate Means for Devs Everywhere
Multifactor authentication (MFA) is becoming increasingly standard within software development organizations, with GitHub recently announcing that two-factor authentication (2FA) will be mandatory for all code contributors by the end of 2023.

This is a smart move. In recent years, bad actors have frequently initiated attacks by accessing source code through the use of stolen developer credentials. Once inside, they quickly penetrate organizations’ entire code repositories and elevate access to company-wide systems. This was the case with the 2021 SolarWinds compromise that ultimately jeopardized federal agencies, corporations and governmental institutions.

But for some developers with lofty goals and concentrated timelines, MFA is an extra step that has the potential to slow them down. As organizations continue to implement MFA and other foundational security controls, they may face pushback—but they shouldn’t be deterred. MFA is a critical attack barrier that improves individual protections and can contribute to tightened source code security.

If organizations approach implementation thoughtfully, they can lay the foundation for subsequent security controls—and build credibility among their users and within the larger development community.

The Risks of Lax Individual Developer Security

Organizations’ source code typically powers a host of upstream programs and products, so it’s valuable for bad actors to launch attacks by infiltrating their repositories. Attackers can also hide malware in source code that can be escalated to breach entire systems and third-party organizations. This risk is heightened by the fact that many companies rely solely on antivirus scans and other surface-level monitoring tools to flag source code vulnerabilities instead of combining them with dynamic testing and penetration testing.

Attackers typically gain access to source code through stolen developer credentials. While single authentication systems—i.e., usernames and passwords—are the easiest to compromise, MFA creates an additional barrier that’s more difficult for attackers to overcome. While this tool does create additional friction in the development process, it’s worth the extra step. Even for hobbyist or open source developers, compromised source code can cause larger repercussions that put other developers at risk. When it comes to cyberattacks, it’s best to assume any entity is a potential target.

Beyond individual security, MFA and other foundational controls are critical to safeguarding organizational reputations and adhering to legal privacy standards. By 2023, 65% of the global population will have personal data covered by privacy regulations. Security measures that protect authentication credentials will become even more important in the coming years, especially for organizations producing source code that powers consumer-facing products and programs. With an intentional approach to implementation, MFA can help mitigate potential source code attacks—and form the basis of comprehensive security programs.

Four Steps to Successful MFA Implementation

The benefits of MFA far outweigh the cost of user friction and developer pushback. Get the most out of this authentication technology by following these four steps to implementation.
1. Start small and build credibility. Approach implementation gradually to help developers understand MFA’s value. Successful implementation will give your leadership and security teams credibility for future security initiatives, and it will improve processes for security integration into your larger software development life cycle.
2. Examine your security program’s value chain. Implementing foundational security controls like MFA provides an opportunity to examine your security program’s entire value chain. Take time to look for potential vulnerabilities beyond your source code repository and flag areas within your development lifecycle that may create risk.
3. Layer subsequent security controls. With MFA under your belt, build up your security program with other tools and controls—like dynamic and penetration testing, source code scanning, software composition analysis (SCA) and vulnerability management. The more security tools you layer, the harder you make it for attackers to succeed.
4. Plan for continuous optimization. Attackers will devise more ways to thwart MFA as more organizations mandate it. For example, the popularity of using SMS as a second form of authentication declined when attackers developed methods to gain control of mobile phones. To keep up with evolving attacker behaviors, continuously optimize your MFA technology and subsequent security controls.
MFA Will Become the Industry Standard

As bad actors evolve attack methods and privacy regulations strengthen, MFA will undoubtedly become an industry standard for protecting source code repositories.

To stay ahead of the curve, focus on the concept of MFA throughout your network by ensuring it protects every system entry point. This extra step is an easy price to pay for improved source code protection—and ultimately safeguards every asset, product and program your code powers. Thoughtfully implementing MFA can lay the foundation for comprehensive source code protection.
August 11, 2022
GitHub Brings 2FA to JavaScript Package Manager

GitHub has made generally available a two-factor authentication tool for the package manager for JavaScript applications maintained by its NPM, Inc. arm.

In addition, all npm packages have been re-signed and there is now an npm command line interface (CLI) command to audit package integrity.

Finally, GitHub has added the ability to connect GitHub and Twitter accounts to npm along with a streamlined login and publishing experience with the npm CLI.

Myles Borins, staff product manager for open source at GitHub, said these enhancements are part of an ongoing effort to enable organizations to better secure their software supply chain by better protecting credentials against being used to take over GitHub accounts.

There isn’t a huge volume of these types of attacks, but it’s apparent cybercriminals are attempting to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, noted Borins. Once cybercriminals gain access, they could potentially insert malware in software components that could find its way into any number of downstream applications. That malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. More troubling still, that malware might begin to spread laterally across an entire application environment.

GitHub is currently dealing with the fallout from a report that its repositories were attacked; that turned out to be a false alarm. The repositories attacked turned out to be either forks or clones of real, popular repositories with names similar to legitimate repositories on the GitHub platform. No malicious code was actually merged into any of the original repositories; however, it’s apparent cybercriminals are using a technique known as spoofing commit metadata to attempt to trick developers into committing code to a fake repository.

The challenge that GitHub is trying to navigate is the degree to which some security controls should be enabled by default based on the level of risk, said Borins. Individual developers, for example, might have a higher tolerance for risk than an enterprise IT organization building an application that is core to the processes that drive the business, he noted. In some cases, organizations may opt to restrict access altogether whenever a user name/password can’t be remembered while others will simply limit access to ensure productivity is maintained, added Borins.

In general, the average enterprise IT organization is likely to have a higher tolerance for disrupting workflows to make sure critical intellectual property is always protected, he added.

The critical issue, of course, is no one knows for sure what open source component might one day wind up in what application. Regardless of the type of application, developers now routinely reuse code that could contain any number of known vulnerabilities or zero-day vulnerabilities that have yet to be discovered. The foundation for building secure DevSecOps workflows for most organizations at a bare minimum is going to start with implementing two-factor authentication, said Borins.

Regardless of the DevSecOps approach, just about everyone recognizes there is a need to better secure software supply chains. The one thing that remains to be determined is what impact achieving that goal might actually have on the rate software is being built and delivered.

August 9, 2022