Are we Forever Doomed to Software Supply Chain Security?

Rate this content

The adoption of open-source software continues to grow and creates significant security concerns for everything from software supply chain attacks in language ecosystem registries to cloud-native application security concerns. In this session, we will explore how developers are targeted as a vehicle for malware distribution, how immensely we depend on open-source maintainers to release timely security fixes, and how the race to the cloud creates new security concerns for developers to cope with, as computing resources turn into infrastructure as code.

17 min
18 Nov, 2021

Video Summary and Transcription

The Talk discusses the importance of software security and the risks associated with open-source software supply chains. It highlights real-world stories of developers' involvement in security incidents and emphasizes the need to trust the software we use. The Talk also addresses the vulnerabilities and targeted attacks that come with the growing dependency on open-source software. It explores the security risks in open-source dependencies, open-source ecosystems, and the future of open source software. Additionally, it provides insights into choosing the best vulnerability scanning software and promoting supply chain security practices.

Available in Español

1. Introduction to Software Supply Chain Risks

Short description:

In this part, I discuss the importance of software security and the risks associated with open-source software supply chains. I share real-world stories of developers' involvement in security incidents and emphasize the need to trust the software we use. Additionally, I highlight the growing dependency on open-source software and the vulnerabilities and targeted attacks that come with it. I also mention Ken Thompson's essay on trusting trust and how developers have been targeted to distribute malicious code. Lastly, I mention the Event Stream incident as an example of a targeted attack on developers in the JavaScript ecosystem.

Hi, everyone, and thank you for joining my talk, Are We Forever Doomed by Software Supply Chain Risks? If you joined this talk, then it means you care about software and you care about software security, which is great. Most of all, you probably are curious, like I am, how does open-source software supply chain risks impact all of us? You, me, everyone here.

So I wanted to begin this with interesting stories, such as, let's take a moment to reflect on this picture, what you're seeing on your screen right now. And what comes to your mind? Is it a futuristic outlook of the world, like the robots? Are they uprising and becoming a key part of our lives? Perhaps it's other things, like how much does the robot actually learn and upload all of that to the cloud? You know, where is it stored? Is it stored safely? What happens when someone can do something malicious with that data? Most of all, what happens if someone hacks in and interacts with my child? This is my kid, if so to say. And what happens when that interaction takes place, when someone is able to compromise that? So, yeah, that's where we are getting started, you know. These are some of the things that are keeping me up at night.

Today I would like to share with you some real-world stories of how developers play a fundamental role in recent and growing security incidents. And also, you know, why should you care about security, software security and software supply chain risks? And also, leave you off to think about who you actually trust.

So, in case you had a doubt, we're seeing more and more open source software being developed. Year after year, right, open source software repositories are growing with more and more open source software and that is more software footprint. The thing is the application that we build are ever-growing in their dependency of open source software, not just the fact that we're using open source software, but the applications themselves are using more and more of that as well. So, more of us, basically, software engineers, are now accustomed to the way of how people work in open source, like opening issues and becoming maintainers of open source. More and more of us are maintainers of open source software and that growth of open source software doesn't come without any risks, right? This is why we're all here, because we care about it.

We are continuously witnessing the growth of open source software security vulnerabilities in these ecosystems, like NPM and Java and others and this could be anything from CVE-based vulnerability reports that when you install a software you get that installation that said, you know, there are 1,000 vulnerabilities there. What happens when that takes place? Also the incidents themselves of malicious packages and different targeted attacks on developers because us as developers, we rely on open source software packages and so we are targeted as well and we'll get to that right now.

Let's rewind back, first of all, in time to get an early glimpse of how one developer perceived the risks of open source software. So in 1984, the Turing Award-winning Ken Thompson wrote a short essay titled, Reflections on Trusting Trust, in which he describes how he added a backdoor to the Unix login C program and then he continued and added a backdoor to the C compiler and then he added a backdoor further on with his chains of attacks into the compiler that compiles the C program, that compiles the compiler. Right, so in his paper here about Reflections on Trusting Trust, he actually explains how software can be taught to learn specific traits and pass them on. So, realistically, it is very, very hard to find the traces of things like Trojan horses and backdoors unless you have actually written everything from scratch. And I mean everything such as the compiler, the linker, the CPU, the display that you're watching something, the keyboard, everything. It is very hard to trust an ecosystem. So as we learned by Thompson's Trojan horse story, this is dating back to 1984, developers have been targeted as a vehicle to distribute malicious backdoors and other sorts of malware for a very long time now.

Let's explore some of these incidents. I'm sure you've probably heard of some of them. In 2018, the JavaScript ecosystem witnessed its first high impact, spearheaded, targeted attack on maintainers and developers alike where they are working in open source in the ecosystem themselves and actually have been the attack target, the vehicle as well to actually distribute malicious JavaScript code to all of us using those software. And so the attack itself targeted also developers using open source, specifically a Bitcoin wallet application. And this was the well-known Event Stream incident. Event Stream existed on the NPM registry since 2011, for a very long time now, as you could see. It's practically didn't receive any new releases in the last two years. But gained millions of downloads per week.

2. Security Risks in Open-Source Dependencies

Short description:

Someone unexpectedly offers to help with a project and opens a pull request. Unbeknownst to the original maintainer, the trusted individual introduces a dependency with a backdoor. The dependency is then included in new versions of the software, compromising its security. This incident occurred with the Event Stream package, resulting in the distribution of a malware-infected Bitcoin wallet application for three months.

Out of the blue someone chimes in and say, I wanna help. They get into the project, they help, they open a pull request as you normally do in open-source software. One of those pull requests later has actually introduced the dependency. At that point in time, this was a trusted individual. So they received a different kind of like access to the repository, and publishing new packages, and new versions of that package, and so on. And later on when they added that dependency, now that dependency exists in a different state, and they could just add that backdoor to that new version that they released. And now new versions of Event Stream that use that dependency pull that, the new version in, and they get that dependency with the backdoor that now the original maintainer of Event Stream did not know about. They did not know that this is happening and they can't control it. Because this is how software package managers work in specific ecosystems like NPM, like others. So this actually resulted in two versions of the copy Bitcoin wallet application, including the malware, three months. For three months until we found this, this is the Event Stream one.

3. Open Source Security and Vulnerabilities

Short description:

An academic research paper found that 61% of open source packages on NPM are considered abandoned. Similar incidents to the Event Stream story occurred with Electronative Notify, where a new version with malware was released. The security of our development infrastructure, such as cloud instances and continuous integration tooling, is often overlooked. A security researcher broke into Microsoft Visual Studio Code's GitHub repository, highlighting the need to understand the current state of open source security. Python and JavaScript maintainers take an average of 100 days to start mitigating a newly published security vulnerability. The case study of Marked, a popular Markdown library, reveals the challenges faced by open source maintainers in addressing security vulnerabilities. The question of trust and the need for mitigations and controls in open source software cannot be ignored.

Now, an academic research paper published in 2019 investigated this properties of language-based software ecosystems, and it found that more than a half, 61% of open source packages on NPM could be considered abandoned because they did not receive any release in the last 12 months. That's exactly what happened with the Event Stream story. And as if we didn't learn anything from this incident, one year later, a similar action comes into life, Electronative Notify, and similar incident happening. What happening in short, this one point in time, this existing Electronative Notify package, which is not malicious, but it's added as a dependency to a different project, this EasyDEX GUI thing. Later on, the developer that owns Electronative Notify releases a new version that now includes a malware, a backdoor to it. What happens, the Electronative Notify project is now embedded into a different app, this EasyDEX things, which now pulls a new version of Electronative Notify with the malicious version and releases new versions. Again, sounds similar? Exactly what happened before. How much thought are we actually giving to the security of our own development infrastructure? For example, resources like Cloud instances and your continuous integration tooling. In January 2021, a security researcher broke into Microsoft Visual Studio code, GitHub repository. Essentially, this is providing him any capabilities like read and write access to modify the code, of the very well beloved IDE VS code that many developers love. But due to command injection that this researcher had been able to exploit, it was able to give him an attack vector to basically create code injection. Now, by opening a pull request, all he had to do, open a new code pull request, this researcher can now execute code into VS code's own CI ecosystems without being authenticated or authorized. All of this really just provides him the ability to create, to submit, or if you would like to say, spawn remote reverse shells on the CI servers running code. And from that, being able to basically push and write access to the repository itself. Now, fortunately for us, all of us here in this ecosystem, this researcher responsibly reported the flaw to Microsoft before, hopefully anyone else could have gained access to it. But you have to ask, right? How much do we know about the current state of open source security? What does it actually entail? So in an effort to explore the security awareness of Python and JavaScript open source communities, a group of researchers investigated how maintainers work in the open source community and how they release fixes relating to security vulnerabilities. One of the research questions was how quickly do maintainers mitigate a newly published security vulnerability? Once it's published, once there's a CDE out, the research found that it takes almost 100 days on average for both JavaScript and Python maintainers to start mitigating a vulnerability. You have to ask yourself if this is fast enough. And this is a bit different between the different communities because for Python, it has been remediated much sooner versus JavaScript, which took its time from 2018 until now to basically be a bit more mature and aware about the security risks. As a case study exactly of this, we can refer to Marked. It's a library, Marked's own security vulnerabilities from several years back. Now, what happened is Marked is a Markdown library. It's a parser for, you know, JavaScript and Node.js and it's very popular, getting millions of downloads a week. One day a security researcher just pops up, open a code pull request to fix a vulnerability. So this says, all you have to do is merge it, basically, as you can see here. But, as it is with open source software, maintainers are really trying to do their best, but they're not contracted or obligated legally or something to support you. So, me as a maintainer, you, everyone else, we're really trying to do our best in time of what we can do. But this vulnerability stayed out there for a year, knowingly, exact what's happening with this, and this security vulnerability itself being public for more than a year. When we're all so much very dependent on open source software, we can't ignore the question of, you know, where do we put our trust? What are the mitigations and controls that we have to cope with the risks involved? In 2017, a security researcher working with the Node.js Foundation, conducted a research, which he wanted to explore and assess, right, the state of weak NPM credentials on the NPM registry. His work really revealed devastating truths about developers and their lack of security hygiene.

4. Security Risks in Open Source Ecosystems

Short description:

A security researcher gained access to 14% of NPM ecosystem modules, including widely-used packages. Insecure passwords chosen by well-known maintainer accounts were a major issue. Despite the availability of two-factor authentication, only a small percentage of NPM package maintainers have enabled it. Humans are often the weakest link in the security chain. The sudo utility had a security vulnerability that went unnoticed for 10 years. We all play a part in the open source ecosystem, where 90% of our application code is open source. Open source registries can be vulnerable to malicious packages, and the removal of packages can cause widespread issues. Enterprises and organizations need to better understand how to handle open source software and registries.

What I mean by that is, this security researcher was able to gain published access to 14% of NPM ecosystem modules. This is a lot. Some of these modules were downloaded millions of times, tens of millions of times a week. And they are still an essential key part of this thriving JavaScript ecosystem, which I am also a part of. So this is very concerning for me, as well.

The thing is, the problem was rooted with insecure passwords chosen by well-known maintainer accounts, such as literally the word password for one of the accounts running millions of downloads for one of their packages. So if it can happen to them, it can happen to other packages, as well. If our code packages can reach millions of developers, shouldn't we have more protections in place as citizens of open source communities? Shouldn't we do better for our account hygiene? So you would imagine so.

But in NPM, the largest registry of open-source software, even though two-factor authentication was enabled since 2017, only 7.1% of NPM package maintainers have enabled 2FA. You'd think that we have done better so far, but a year later, by 2020, another interesting insight that we get into what has been happening is that it has only grown by 2%. Only 9% of developer account on NPM by 2020 have enabled 2FA. We should do better.

As cybersecurity expert Bruce Schneier says, and had said and written in his book, 'Secrets and Lies,' humans often represent the weakest link in the chain. Given enough eyeballs, all bags are shallow. As a term coined, as Linux is low, backed by Eric Raymond in his work, the Cathedral and the Bazaar by 1999. He explored the differences of how software development takes different shifts between open source and enterprises. And one of the things was that if everyone are looking at it, you know, we'll find the problems or a lot of people looking at this code. Really, are we going to find it? Because in January, 2021, it was discovered that sudo, the common utility installed on many Linux distributions had a security vulnerability. Specifically, it allowed any unprivileged users to gain root access simply by the default sudo configuration. Now, this was so daunting as a vulnerability because it was hiding in plain sight. This is from the, you know, the disclosure itself. For a whole 10, whole years, this was just showing up there.

We can't deny being a part of this open source ecosystems as consumers, contributors, or maybe even as maintainers for some of us. We all play some parts in a world where 90% of our application code is open source software components. We reached a point where, you know, we take open source for granted, right? Open source registries are open in their nature. Anyone can go in and publish their new packages, even malicious ones, you know, we will be surprised, maybe it doesn't get caught. We have been accustomed to this, you know, opening and issuing a project source code or asking for help, asking for a feature, you know, asking someone to get our bag fixed hopefully. But we import those open source into our projects and do we understand what's going on at that point in time? Because open source registries are open in their nature, but they're not gonna be there all the time. What happens when maintainers remove their packages and dependencies? And this is a story that exactly happened and for a package that was very pivotal in the ecosystems, but caused a widespread breakage of continuous integration systems all around. So at the very least, it taught us that enterprises and organizations that were prompted this attack were not understanding how to deal with open source software and registries themselves did not know either.

5. Risks and Questions in Open Source Software

Short description:

Open source software poses risks in terms of malicious activities and assets. The NPM and PyPI ecosystems have seen an increase in malicious packages being published. Alex Berchan's research demonstrates how attackers exploit design flaws and human errors to infiltrate corporations. The future of software and the use of open source software raise questions about trust and security.

They were missing how even this could be possible and wouldn't be possible. What kind of malicious activities and assets can we track back to open source software? Time after time, we're finding more malicious packages hitting the NPM ecosystem, typo spawning mistakes and others. But they're not only a sole problem of the NPM, the JavaScript ecosystem, because PyPI had also seen thousands of packages brute forcingly published in bulk to basically add malicious packages.

To further show us how attackers can actually harness open source to their advantage, Alex Berchan published his research in February 2021 about how he exploited design flaws in package managers and human errors and registries basically to infiltrate into corporations like Apple, Microsoft, and others. And so all of this is happening in open source.

And I would like to leave you off with some questions. Are we going to have less or more software in the future? Are we going to use more open source software in the future? Who do you trust and what can you do about it? Thank you for coming to my talk. My name is Iran Tal, I am a developer advocate at Snyk where we build a security platform to help developers build securely with open source software. Thank you all for joining my talk. Have a nice conference.

6. Importance of Security and Recent Incidents

Short description:

That was a wonderful session. Security is important for web development. Trojan source and event stream are recent attacks on the NPM supply chain ecosystem. CodeCuff is a Docker-related security problem. Trojan source is an academic paper describing how bad code can be injected into open source projects. CodeCov had a serious security incident due to a leaking Docker image. Security incidents and supply-chain security are widespread. Security is an essential part of software development.

That was a wonderful session. I am super glad that Liran brought this topic today because security is something that is very important for web development. And yeah, thanks for that.

So let's take a look at the results of the pool. And as we can see here, it seems that people hear a lot more about Trojan source than any of the other options that you left there. What's your comments on that, Liran?

Yeah, that makes a lot of sense because I guess a lot of Trojan source has been in the news recently. That's more recent than the others, but they are different types of attacks. And that's why I gave them that kind of shows you got, what are you seeing? Which is a lot of the media stuff. But for example, an event stream, which, you know, if you didn't know about before, then you should probably know now because of like, I was chatting about it on my slides just in this talk. It's one of the most sophisticated attacks that we've seen on like the supply chain ecosystem for NPM, event stream is. And recently that was 2018, but now we've had recently about a month back, the UA parser agent and COA, and other packages that were probably hijacked and added, they had like malware and cryptocurrency slash ransom kind of malware in them. So that happened pretty recently, but Trojan source, interestingly, that's made it into the news. CodeCuff. Have you heard about CodeCuff before, because that's kind of like a Docker related region of the problem. They haven't. Would you like to talk about them?

Yeah, I'll talk in brief because again, like these are all kinds of different things like Trojan sources from like an academic research paper that caused a whole lot of stuff happening. And it is, Trojan source is not actually an incident, it's more like an academic paper that describes how those sorts of Trojans can, like any bad codes can be injected into open source projects, kind of like using invisible characters and stuff like that. Like by the original unique code characters that changed the way that the text looks. But it still is like the compiler doesn't have any issues with this, because the code is okay. And interestingly, that was like very easily, or I would say very quickly, at least, kind of like addressed where people were both I think, GitHub, Snyk, like a lot of organizations were kind of like acting, responding quickly to fix this and highlight those kinds of issues. So that is very particular case. CodeCov, on the other hand, is we've seen it happening with like the bash uploader security incidents, which stole tokens and stuff like that. So a lot of people using the NPM package for it or the GitHub action for it to like do code coverage, which this is very, sitting this conference, like testing a conference, but the origin of that incident, like why did it happen is simply due to the Docker image that was built for the CodeCov tool chain was actually leaking, had some layers inside, actually leaked private keys that allowed someone when they looked at it and like, you know, know where to change files, how to change them. It went on for like four months until this got discovered. So like super serious issue as well. And it was addressed, you know, very well by the CodeCov team with a lot of transparency and incident response on this. So like, you know, kudos to them to handle this, but it just shows like, you know, security incidents and supply-chain security is just all around. So that's kind of like. It just shows how security is important. And we have, we don't, we can't just look into one part of the testing because security is part of the software development in general, right? So we have some questions.

7. Choosing the Best Vulnerability Scanning Software

Short description:

To determine the best vulnerability scanning software, consider software composition analysis (SCA) that looks at your package managers' files and tracks vulnerabilities based on versions. It's important to have developer-focused workflows to help fix issues and a reliable vulnerability database. These traits make a software better.

And the first one is from Jim Nuro. Is a solution better vulnerability scanning software? I don't know if I understood exactly the question. Did you get it? Is a solution better vulnerability scanning software? Okay so there are a few. I will not discuss the whole sort of like the spectrum of like a security testing software. There's a bunch, but mostly you probably wanna have the SCA because we use a lot of open source. SCA means software composition analysis. It's basically looking at your requirements that decks, you know, Ruby gems files, all of the like packages and all of those package managers related files. Checking out which has vulnerabilities in them depending on the versions and then tracking that towards a vulnerability database. Now that's important to have because we rely a lot on open source and you can see a lot of like these incidents related to open source dependencies. So what is better, right? It's kind of like, you know, it's very much like, what works really well for you and that's like super important. But I would say there are two things that would make a software better. I think for me, when you do the vulnerabilities, one is it has to have like developer related workflows in mind. So not just to show you the problem but actually help you fix them and like, you know, help developers like actually remediate the issues. And the other one is a very, very good vulnerability database because if you have something that just works but it doesn't really cover a lot of like the vulnerabilities or doesn't cover them on time or it's like has a lot of false positives, all of those things that kind of like add noise and in the end you'll just end up getting frustrated and not to use this. So these are two traits and features that I'd look into a software that does that.

8. Envisioning the Future and Developer Tools

Short description:

The open source security foundation is working on best practices and tooling to address package tampering issues. Projects like SIG store focus on authenticity and integrity to make packages safer. However, solving this issue may lead to new threats. Implementing tools like Dependabot can help automate vulnerability fixes, but it's important to manage the number of pull requests to avoid overwhelming the team. Snyk offers developer-oriented tools and allows users to limit the number of upgrade requests for better management.

Awesome. There's another question here, which is how do you envision the future yourself? Do you envision your own utopia for package security? It's an interesting one. Yeah, but could you repeat it's a vision of what I didn't really catch that one. How do you envision the future yourself? Do you envision your own utopia for package security? Oh, I got it. Okay. So I'll tell you what the ecosystem looks at right now from being involved in a lot of like working groups and security forums and things like that. There's a lot of work right now being done in the open SSF to this is the open source security foundation recently by the way kind of like a relatively recently kind of created. And the idea there is that's kind of like prevailing is first of all, a lot of best practices. Like first of all, we need to get developers, engineers ops security, everyone kind of like knowing what to do best for the best practices, how to do them. So this is why I'm doing these talks, like helping developers like writing blog posts where practices to all of those kinds of things. So people could like upskill themselves. Like this is like half of the problem. The other it's the other is like tooling and there is definitely like some work around SIG store and other projects which are basically if you like Google's SIG store, you'll find it really quick. The idea is how do we right now a lot of those issues or because we cannot trust that the package wasn't tampered with. So like if I publish the package on NPM and you downloaded it, you do not know if this new version was really signed like an integrity check that was really me producing it or someone else that's had a takeover of my account like they know that username and password and they did it but they don't have access to my private key or something like that. So like they couldn't give you that kind of like a feeling of safety. So SIG store and other tooling around this is really more about the authenticity, the integrity everything around the package that makes it hopefully like will make our lives a lot safer but I'm pretty sure we're gonna see more threats once we solve that one, right? Like it's a rolling ball. Yeah, yeah. I want to ask a question before we go with the next one which is like I have in a previous experience implemented in a JavaScript code base the Dependabot from GitHub where it automatically sends you pull requests fixing vulnerability issues and things like that. Do you have any comments on doing that and how often, because in the beginning it was funny because it was just too many pull requests and we have to limit how many we wanted to review every week so that we could work on other stuff as well. And at some point, it became like a more of a number that we could manage, but I wanted to hear your opinion on that. Yeah, and I think it's a good example. Like if NPM Auditor dependent but works for you, I mean, that's good. That means that maybe you're happy with this and that's okay. I'll tell you what are the addressing specifically your concern? Like what are the more developer oriented tools are and that kind of what we're doing at Snyk. And so one of those first issues that you just said, like you are concerned because it's flooding you with maybe hundreds or tens of full requests. So on Snyk, what you could do is you could say, Hey, you know what, I want to limit my upgrade requests of packages to like, say five. I don't know whatever numbers make sense for your team, but let's say it's five. So Snyk knows that it will not open more upgrade full requests if there are already five open, of course like the security one will always open up because I want to keep you safe and protected. You should like upgrade as soon as you can.

9. Promoting Supply Chain Security Practices

Short description:

Updating quickly can sometimes be risky, as it may introduce malicious versions. Snyk has developer-first tooling for a safe and comfortable environment. They have analyzed prior security incidents and determined an optimal timeline for introducing new package versions. Promoting supply chain security practices involves raising awareness, discussing with colleagues, and following best practices. The Snyk blog and various tools provide valuable resources. The more we talk about and use these tools, the better we can promote supply chain security.

But all the general chatter around, like the full request chatter about like opening more and more and more just to stay up to date. We always limit that to an extent. And that helps your team kind of like have that control of like how to do things. So it sounds like a small feature, but it's like just it's exactly that developer first kind of mindsets tooling that Snyk has, which is, you know, free and like open source with CLI and tooling. So like, that's really addresses developers in terms of like how they should like, you know, work in a very kind of safe and comfortable environment.

The other... Completely says, yeah. Sure, yeah. The other aspect of it is for example, we were looking at some security incidents in the past before. And one of the things that we learned is, which also like relates to what you said, with a lot of like the, you know, flooding you with those baggage updates. And that is sometimes like updating very, very quickly is actually bad, right? Because if this is now in like version three, five, two, whatever, is like the newest version you, and someone tells you like upgrades is dependable or something else, updated this and then like two weeks later, you found out you upgraded, you know, too fast. And now this is a malicious version, like UA parser COV, et cetera. Then upgrading really, really fast, actually puts you in a position of risk. So we've actually done this even like, I think two years ago already, like 2020, even maybe 2020, 2019, where we analyze some of like the prior security incidents that happened, and we figured out what is an optimal timeline where we will introduce a new package version, which is not too soon, but also like not too late. And I think that's kind of like 20 or 21 days. And so if there's like a new package, we will not tell you about it until 20 or 21 days. And afterwards you cannot, we will. So like that's kind of like, you know, have been, there's like some safety around it. That's super nice. That's super.

And last question, how can we better promote supply chain security practices? Best question. You know, it's a lot. Like, you know, help me raise the awareness, you know, talk about it with your friends, with your colleagues, you know, do the best practices. There is a ton of learning on the sneak blog. If you kind of like Google like best practices for NPM or Noders Java, you'll find a ton of the stuff that we've been writing, like cheat sheets and PDFs and everything from like tooling that we're building. And the idea is really just to help you. And, you know, I'm a developer myself. I write all of these tools, actually wrote an ES linked plugin to detect and prevent you from having Trojan source attacks, which, you know, a lot of people here said that they knew of, so like, why not use it? We're doing a lot in a lot of like activism to like really promote awareness of supply chain security, open source security in general. And you know, the more that we talk about it, the more that we use the tooling, the more that we take responsibility for what we use and the due diligence that we do is, you know, one step further to actually like, you know, promote the whole notion for everyone else and advance this story. Yeah, a final question from myself, which resources do you recommend for reading about like security testing? There's quite a few.

10. Using OS for Developers

Short description:

OS has a cheat sheet series, including OSASVS and Proactive Controls, which are developer-oriented. However, the documentation and terminology may be overwhelming for developers not familiar with security concepts.

I mean, OS is pretty good in terms of, like they have a cheat sheet series, which I highly recommend. If you like Google OS cheat sheets, you'll get to create a landing page with a ton of those. There's the OSASVS and which is like, and the Proactive Controls which are, Proactive Controls is very developer-oriented. I would say the only kind of like caveat bit with OS is that it's still very, sort of security-minded. So like it's kind of geared towards security people, not towards developers in a sense, like the documentation, the way that stuff are built, the terminology. So it could be very overwhelming when you read this as a developer and you hear, like you read on the screen, like CVEs, CVSS Core, like a lot of stuff that you may not know of and like it will deter you away.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.