What is a Vulnerability and What’s Not? Making Sense of Node.js and Express Threat Models

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Slides
Rate this content

Security isn’t just about fixing bugs; it’s about understanding the assumptions we make (and avoiding unnecessary panic). In this talk, we’ll dive into the Node.js and Express threat models, which I co-authored, to break down what they trust, what they don’t, and why that actually matters for developers and security researchers.

We’ll take a look at real-world vulnerabilities that fit within these models, clear up some of the most common security misconceptions (because not everything is a critical meltdown), and explore how these security assumptions influence bug bounties, exploitability, and long-term fixes. By the end, attendees will walk away with a much better sense of what’s a real security risk, what isn’t, and how to build applications that won’t keep them up at night.

This talk has been presented at Node Congress 2025, check out the latest edition of this JavaScript Conference.

FAQ

A vulnerability is a flaw, security misconfiguration, or weak point in a system that can be exploited by third parties to behave in unintended ways.

A threat model is a structured approach to identify security risks, possible mitigations, attackers, and actors, and to understand what can go wrong in a system.

Developers are responsible for validating and sanitizing input, managing dependencies, handling errors properly, and implementing security measures such as security headers and monitoring.

The shared responsibility model outlines the division of security responsibilities between cloud service providers and users, where providers manage infrastructure security, and users handle data and application security.

Best practices include input validation, understanding authentication, using security headers, regularly auditing dependencies, and implementing resource limits and proper error handling.

Threat models help developers understand potential security threats, define boundaries of trust, and guide the implementation of security measures in their projects.

Tools like Snyk and Socket can help manage security by auditing dependencies and identifying vulnerabilities in Node.js applications.

Prototype pollution is a vulnerability in JavaScript where an attacker can manipulate the prototype of an object, potentially leading to unexpected behavior and security risks.

Ulisses Gascon is a software engineer at NodeSource and a core team member of Yeoman, Node.js, and Express, focusing on security in the ecosystem.

Common vulnerabilities include SQL injections and misconfigurations in libraries like Express, which can lead to denial of service or other security issues.

Ulises Gascón
Ulises Gascón
17 min
17 Apr, 2025

Comments

Sign in or register to post your comment.
  • Costanza
    Costanza
    Bromley web works. Founder
    👍
Video Summary and Transcription
In this talk, we will discuss security, vulnerabilities, and how to improve your overall security. We will explore various vulnerabilities and the difference between developer errors and misconfigurations. Understanding threat models is crucial in determining responsibility for vulnerabilities. Developers have the ultimate responsibility for handling user input, network data, and other factors. Understanding threat models, best practices, and taking ownership of dependencies are key to improving security. Security is an ongoing process that requires dedication and understanding.

1. Introduction to Security and Vulnerabilities

Short description:

In this talk, we will discuss security, vulnerabilities, and how to improve your overall security. A vulnerability is a flaw, security misconfiguration, or weak point in our system that can be exploited by third parties. Today, we will explore various vulnerabilities.

Hola, I'm Ulisses Gascon, and in this talk we are going to discuss a lot about security. We are going to go deeply about understanding what is a vulnerability and what is not, while you are using your most loved tools like Node.js or Express, right?

So basically who I am. I am a software engineer at NodeSource. I'm also part of the core team of Yeoman, Node.js, and Express, and I'm trying to help in the ecosystem a lot about security. I'm participating in a lot of collab spaces and working groups and so on. And the idea today is discussing about what is a vulnerability and not, and how you can improve your own security overall.

So basically, what is a vulnerability? In very simple terms, and if we use the Wikipedia, we will understand that a vulnerability is basically a flaw, a security misconfiguration or a weak point in our system. So basically, they are flaws. The thing is, these flaws can be used by third parties to exploit our systems, right? And make them work in ways that we don't anticipate. That's what we consider a security problem. And basically today we are going to discover a lot of these flaws.

2. Understanding Vulnerabilities and Threat Models

Short description:

In the examples given, one is a clear case of developer error with a SQL injection, while the other is a misconfiguration that exposes a vulnerability. Understanding the difference between these two scenarios is crucial in determining the responsibility for vulnerabilities. The talk will focus on threat models, a structured approach to understanding security risks, identifying potential threats, and discussing mitigations. It explores what needs to be protected, potential issues, and boundaries, and provides recommendations for improving security.

The first thing is like, when we face any kind of security challenge, for example, here we have two examples that are actually weak code, let's say. So in the first example, we see clearly that there is a SQL injection here, right? We are not doing any kind of validation on this data.name, right, basically. So that's something that can be bad. And in the second example, we don't see nothing especially weird aside of this huge limit that we say in one of the arguments when we did the configuration for the body parser. But yeah, basically we are using Express, nothing super weird and body parser, right? So in the first example, it's very clear for us that maybe who we can blame, basically might be the developer.

And in the second case, it's not very clear, right? Because depending on how you are managing this, you have two perspectives here. So one is like, if you have a SQL injection, that is how you are using the tool and you are using the tool wrongly. So in this case, for example, is blaming the developer, right, to make the mistake to include the SQL injection. But in the other case, it's not that simple. It's mostly our vulnerability, right? So we define how the framework should work, how the libraries should work in this case. And there is a misconfiguration from the decision that we made in the project that make this weak point possible to be exploited, right? So we got a CVE the last year and we can see clearly that this can end up on a denial of service because there are some options to make, you know, crafted payloads that might, you know, float over server. So this is the kind of scenarios that we deal. We are going to discuss a lot today on what are the two main difference between these kind of things and how we can understand and expect what is considered a vulnerability in the eyes of the developer and what is considered a vulnerability in the eyes of the maintainers of the libraries or the runtime that you love to use, right?

So basically, the most important thing today, the introduction of this talk is going to be about the threat models. So basically, what is a threat model? So for us, a threat model is a simple document. I mean, the final output is a document, but mostly it's a structured approach to understand the security risk, possible mitigations, we try to identify the attackers and the actors and what can go wrong. So basically, it's an exercise that we do as part of the project and we try to respond to some of these questions, right? Like what we are trying to protect, you know, what can go wrong? What are the issues that we might see around this? What are the potential threats that we are seeing here? It is something that can be caused by a misunderstanding, can be a bot, can be, you know, attackers, can be whatever, right? What are the boundaries? That is a very important question that we should ask when we build a library, when we build a runtime, right? Like what are the things that we consider trustfully or not trustfully so we can understand that. And also we discuss a lot about the mitigations, right? What, what we need to do, I mean, how are the scenarios and what the users of our own environments can do to improve the security, right? And we build the recommendations and so on so that people get a better understanding on how this works.

3. Threat Models and Developer Responsibility

Short description:

Threat models are essential tools for understanding vulnerabilities in libraries and runtimes like Node.js and Express. These models are based on trust and help researchers determine what is considered a vulnerability. However, it is crucial to understand that while frameworks provide mechanisms to prevent certain vulnerabilities, developers have the ultimate responsibility for handling user input, network data, and other factors.

You can find these threat models, for example, in the case of Node.js, inside of the security.mt document, which is a fantastic document. If you want to understand a little bit more about how Node.js take the security seriously and understand what are the processes and how you can report vulnerabilities and so on.

And the threat model, most of the time is used a lot by the researchers to understand what we consider a vulnerability or not. And this is a lot based on what we trust and we don't trust. And the same goes for Express, right? We have a specific threat model which is included inside of the security working group of the Express organization. And basically, if we take both models, both documents together and we try to combine some ideas, we can understand that these libraries and the runtime basically are trusting some things, right?

So from this understanding, you might think like, OK, so basically the framework is taking care of, you know, making some mechanisms to prevent us from the user input and so on. And it's true and false. Right. So basically the idea here is like when we see that we don't trust this kind of thing, it's like when we build applications and we provide you these tools, we should not, you know, just blindly trust the user input as we do for the operating system. But this means that we basically delegate this responsibility into you as a developer. So you should be the one, you know, working on the network data and understanding what's going on there. You should be the one, you know, thinking about the user input and external data and the files that you load in. The, you know, dependencies that you installed as part of the project, these decisions that you made, that's something that you are fully responsible of. And the same goes for other amounts of things. Right.

4. Developer Responsibility and Shared Models

Short description:

Developers have the ultimate responsibility for handling user input, network data, and other factors. The shared responsibility model in cloud services expects developers to take ownership. Depending on the deployment model, developers may be responsible for hardware equipment, physical security, and application configuration. Understanding this threat model is crucial since frameworks and runtimes have their areas of responsibility while developers handle others.

Right. So basically the idea here is like when we see that we don't trust this kind of thing, it's like when we build applications and we provide you these tools, we should not, you know, just blindly trust the user input as we do for the operating system. But this means that we basically delegate this responsibility into you as a developer. So you should be the one, you know, working on the network data and understanding what's going on there. You should be the one, you know, thinking about the user input and external data and the files that you load in. The, you know, dependencies that you installed as part of the project, these decisions that you made, that's something that you are fully responsible of. And the same goes for other amounts of things. Right.

So the amount of things that we blindly trust is very low and the amount of things that we don't trust is a huge list basically. And this is expected from you to take ownership on this. And if you're familiar, you know, with any kind of cloud services, most of the time, especially if you work with Azure, if you work with Google, if you work with AWS and so on, you might get familiar with this shared responsibility model. Right. So so you end up building your application. You want to expose this application to the Internet and you need a server that is running 24-7 and so on with certain conditions to be as much available as possible. Right. Especially if you have if you have a huge, big number of SLAs. Right. So you have a lot of options, right, from the on-premise to PaaS, SaaS models and so on. Right. And if you run on-premise, you are responsible for a lot of things, you know, from the hardware equipment, from the physical security of the equipment and so on, from that physical level to the application configuration. And if you are delegating this and the provider, then you are less responsible for these kind of things. Right. So, for example, if you are using S3 as a service from AWS, you are not responsible of providing the servers, you know, and the physical security so no one can get access physically to those computers, I mean, to those servers and make some manipulation in the hardware and so on. Right. That's how this shared responsibility model works. Right. Depending on on how you structure these responsibilities. So you need to understand this threat model in a very similar way. Like there are things that the frameworks and the runtime are trying to be responsible for. And there are things that we let you the responsibility to handle that.

5. Understanding Threat Models and Best Practices

Short description:

Understanding threat models and how libraries interact is crucial. Key takeaways: validate and sanitize all input, understand authentication, use security headers, and be aware of common web attacks in OWASP top 10. Take full ownership of dependencies.

So it's important to have this very clear. Unfortunately for us, it's not that clear. Like it's not you just cannot make a table and say, like, this is what the libraries do and doesn't. Right. You need to treat every threat model when it's available and understand how these libraries are interacting and taking, you know, the security and the perspective they are using. So that way you understand what is expected, most or less from you to take ownership on.

Best practices that you need to take into account just, you know, some key takeaways from this. So please always do validation and sanitization of any input that you have. It doesn't matter if it's a form input, if it's a URL input, if it's a file input, I mean, any kind of input that, you know, someone can send it to you and can be manipulated and grafted and so on, should be validated. You should understand very well how the authentication works and, you know, having updated policies and strategies and, you know, using the right security approach on this. You need to use, for example, security headers and having a clear understanding of the typical web attacks that you see in the OWASP top 10 and so on, that's important for you as well. You need to, you know, take full ownership on your own dependencies.

6. Dependency Ownership and Security Practices

Short description:

Take full ownership of your dependencies. Understand the security of libraries and review and audit dependencies. Put limits on resource usage for services outside the internet. Manage cookies properly and handle errors and logging. Prioritize security and be aware of common vulnerabilities like prototype pollution and malicious third-party packages.

You need to, you know, take full ownership on your own dependencies. I mean, dependencies are great. We there are like millions of packages right now on NPM that we can use to speed up how we don't work, right? And we don't have to rebuild every second, every project that we do. But it's important to understand that those libraries have some maintainers around, right? And we should be able to understand how the security of these libraries work, if they are maintained or not maintained and so on.

I mean, there are tools already there that we can use, you know, like Snyk and Socket and so on. But it's important that you include this, you know, review and audit of these kind of dependencies and having this, you know, updated them over the time. So include this in your development life cycle.

You need to understand as well that if you, you know, create any kind of service that is outside and available on the internet, you have to, you know, put some limits on the use of resources, right? It can be like the typical API, apply for it limits on the APIs, calls, you know, limit the communications, IP restrictions, you know, having policies, these kinds of things. As well, you need to understand how to manage the cookies, you know, sensitive data exposure is a very common thing, especially when we have errors on the server.

I see, unfortunately, recently, a lot of scenarios where the people didn't handle properly the errors on the server and you end up sending this information back as the content of the request and so on. So you basically are providing even much more information that needed to a potential attacker as well. So that's important, you need to handle errors properly. And you need to log these kind of things as well, right? You need to have a proper logging in place so you can understand what happened with every request and what's going on in your server on the services that you have online. So later on, you can do a proper outlet and trace what happened and understand what's going on, right? Not only for misconfiguration and books and errors, but also in terms of security, understanding how the people are exploiting your system will help you to understand how to secure them basically. And you need to have some kind of security monitoring and so on.

I'm saying a lot of things, right? So you end up having a big list. So prioritization is important. So let me show you some real-world vulnerabilities that might be quite common or I see quite common. So prototype pollution is one of the most tricky things in my experience. I see this a lot. It's a very common thing in JavaScript. We have some mechanisms in Node.js and Express to prevent these kinds of things. But we don't do that for the payloads that they send you, right? So you need to be clear that when someone sends you like a JSON or so on, you can see there a lot of malicious payloads that can force this kind of prototype pollution. So it's important to understand in this how it works deeply and also to do these sanitizations.

For example, it's understood that people think that Express provides you like a, you know, pretty full security headers on place. So you have a lot of policies and so on on the headers and these make your application much more secure. Actually, Express doesn't do that today. But there are libraries that help you with that, like Helmet, right? So it's important to understand these kinds of things because we'll reduce a lot the surface for attack on your applications. Malicious third-party packages. This is a very common thing.

7. Understanding Dependencies and Security Processes

Short description:

Understand dependencies, CVEs, and set limits on data received. Not all security issues are vulnerabilities. Developers play a key role in understanding boundaries, threat models, and building security policies. Security is an ongoing process that requires dedication and understanding. Resources and examples are provided for further learning.

You depend on a lot of things and the things that you depend on depend on more things and so on. So you basically have a huge full play chain. And that's unfortunately will add you more work because you need to have a real control and understanding of what's going on there and having some strategies to mitigate this. This requires as well that you understand how CVEs work, how, you know, when you need a CVE that has been published recently in one of your libraries. This is affecting you. You need to migrate. You need to change. I mean, you need to take decisions and basically take ownership on this. And it's a full work on their own.

As well, you need to understand everything that the people can send you, for example, especially files and stuff like that. You need to understand how are the limits, right? So as we say before, the same way that you put limits on the API, you have to put limits on the length of the things that they can send you, especially in files and stuff like that. So don't get exhausted in terms of lacking of space, services, and so on.

Basically, as a conclusion, just first conclusion, not all the security issues are vulnerabilities, right? At the end, we are discussing about flaws in your system that someone might, at a certain point, use that to exploit your own system. That's the thing, right? And make the software work in a way that you didn't expect it. So that's how, when someone really explodes your system. The most weaknesses you have in your system, the highest is the chance to get the vulnerability and that goes to security incidents. So basically, if you understand the vulnerabilities and the surface that you have, it's going to help you a lot. Developers are doing a key role here, as we say before. I mean, we have a certain responsibility between the library creators and maintainers, like myself, and all the developers that are using the things that we build and create, right? So we need to understand and have a good relationship here. And especially as a developer, you need to understand where I set my boundaries as a maintainer. So you understand where do you need to take more responsibility on the things that we do. And the same goes for the thread models, right? If you understand really well how these thread models work, it can help you a lot. As well, these thread models only not help you to understand the libraries. You can use these kind of thread models to help you to build your own thread models for your own surface, your own projects, and so on, and get a better understanding of what's going on. Because security is a huge matter. It's a huge matter not only because the importance it has, it's also because the surface and the amount of time that it might require from you, right? So it feels like a huge thing to accomplish. And it's not something that you can just accomplish one day or just invest in like, you know, one quarter dedicated to that. And from that moment on, you are secure and you forget about it. It's something that it will be together with your application, as long as you're running the Internet and you still have a surface that someone can attack, right? So basically, you need to understand and take everything seriously. But you also need to, you know, understand how these flows are there and will be there. So you need to have some policies in place and some ideas of what's going on. I included as well here some resources. So basically, you can, you know, go deeply on this and understand more things. You have also some examples on how, for example, we can create a very simple backdoor on Express Middleware and how you can inherit this into your application. How the CVs works in terms of how do the patterns run, as well the threat models that we say before. Well, thank you so much for watching this session. I really like the idea of sharing this knowledge with all of you. I hope that you have the opportunity to learn something new today and I'm really open to have a lot of discussions about security on social media at any time. So thank you so much for being here and share this time with me.

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

It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
The State of Passwordless Auth on the Web
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Passwords are terrible and easily hacked, with most people not using password managers. The credential management API and autocomplete attribute can improve user experience and security. Two-factor authentication enhances security but regresses user experience. Passkeys offer a seamless and secure login experience, but browser support may be limited. Recommendations include detecting Passkey support and offering fallbacks to passwords and two-factor authentication.
5 Ways You Could Have Hacked Node.js
JSNation 2023JSNation 2023
22 min
5 Ways You Could Have Hacked Node.js
Top Content
The Node.js security team is responsible for addressing vulnerabilities and receives reports through HackerOne. The Talk discusses various hacking techniques, including DLL injections and DNS rebinding attacks. It also highlights Node.js security vulnerabilities such as HTTP request smuggling and certification validation. The importance of using HTTP proxy tunneling and the experimental permission model in Node.js 20 is emphasized. NearForm, a company specializing in Node.js, offers services for scaling and improving security.
Content Security Policy with Next.js: Leveling Up your Website's Security
React Summit US 2023React Summit US 2023
9 min
Content Security Policy with Next.js: Leveling Up your Website's Security
Top Content
Watch video: Content Security Policy with Next.js: Leveling Up your Website's Security
Lucas Estevão, a Principal UI Engineer and Technical Manager at Avenue Code, discusses how to implement Content Security Policy (CSP) with Next.js to enhance website security. He explains that CSP is a security layer that protects against cross-site scripting and data injection attacks by restricting browser functionality. The talk covers adding CSP to an XJS application using meta tags or headers, and demonstrates the use of the 'nonce' attribute for allowing inline scripts securely. Estevão also highlights the importance of using content security reports to identify and improve application security.
How React Applications Get Hacked in the Real-World
React Summit 2022React Summit 2022
7 min
How React Applications Get Hacked in the Real-World
Top Content
How to hack a RealWorld live React application in seven minutes. Tips, best practices, and pitfalls when writing React code. XSS and cross-site scripting in React. React's secure by default, but not always. The first thing to discover: adding a link to a React application. React code vulnerability: cross-site scripting with Twitter link. React doesn't sanitize or output H ref attributes. Fix attempts: detect JavaScript, use dummy hashtag, transition to lowercase. Control corrector exploit. Best practices: avoid denialist approach, sanitize user inputs. React's lack of sanitization and output encoding for user inputs. Exploring XSS vulnerabilities and the need to pretty print JSON. The React JSON pretty package and its potential XSS risks. The importance of context encoding and secure coding practices.
Let Me Show You How React Applications Get Hacked in the Real-World
React Advanced 2021React Advanced 2021
22 min
Let Me Show You How React Applications Get Hacked in the Real-World
Top Content
React's default security against XSS vulnerabilities, exploring and fixing XSS vulnerabilities in React, exploring control characters and security issues, exploring an alternative solution for JSON parsing, and exploring JSON input and third-party dependencies.

Workshops on related topic

Hands-On Workshop: Introduction to Pentesting for Web Apps / Web APIs
JSNation US 2024JSNation US 2024
148 min
Hands-On Workshop: Introduction to Pentesting for Web Apps / Web APIs
Featured Workshop
Gregor Biswanger
Gregor Biswanger
In this hands-on workshop, you will be equipped with the tools to effectively test the security of web applications. This course is designed for beginners as well as those already familiar with web application security testing who wish to expand their knowledge. In a world where websites play an increasingly central role, ensuring the security of these technologies is crucial. Understanding the attacker's perspective and knowing the appropriate defense mechanisms have become essential skills for IT professionals.This workshop, led by the renowned trainer Gregor Biswanger, will guide you through the use of industry-standard pentesting tools such as Burp Suite, OWASP ZAP, and the professional pentesting framework Metasploit. You will learn how to identify and exploit common vulnerabilities in web applications. Through practical exercises and challenges, you will be able to put your theoretical knowledge into practice and expand it. In this course, you will acquire the fundamental skills necessary to protect your websites from attacks and enhance the security of your systems.
0 to Auth in an hour with ReactJS
React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Kevin Gao
Kevin Gao
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
OWASP Top Ten Security Vulnerabilities in Node.js
JSNation 2024JSNation 2024
97 min
OWASP Top Ten Security Vulnerabilities in Node.js
Workshop
Marco Ippolito
Marco Ippolito
In this workshop, we'll cover the top 10 most common vulnerabilities and critical security risks identified by OWASP, which is a trusted authority in Web Application Security.During the workshop, you will learn how to prevent these vulnerabilities and develop the ability to recognize them in web applications.The workshop includes 10 code challenges that represent each of the OWASP's most common vulnerabilities. There will be given hints to help solve the vulnerabilities and pass the tests.The trainer will also provide detailed explanations, slides, and real-life examples in Node.js to help understand the problems better. Additionally, you'll gain insights from a Node.js Maintainer who will share how they manage security within a large project.It's suitable for Node.js Developers of all skill levels, from beginners to experts, it requires a general knowledge of web application and JavaScript.
Table of contents:- Broken Access Control- Cryptographic Failures- Injection- Insecure Design- Security Misconfiguration- Vulnerable and Outdated Components- Identification and Authentication Failures- Software and Data Integrity Failures- Security Logging and Monitoring Failures- Server-Side Request Forgery
How to Build Front-End Access Control with NFTs
JSNation 2024JSNation 2024
88 min
How to Build Front-End Access Control with NFTs
WorkshopFree
Solange Gueiros
Solange Gueiros
Understand the fundamentals of NFT technology and its application in bolstering web security. Through practical demonstrations and hands-on exercises, attendees will learn how to seamlessly integrate NFT-based access control mechanisms into their front-end development projects.
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
JSNation 2022JSNation 2022
99 min
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
Workshop
Matthew Salmon
Matthew Salmon
npm and security, how much do you know about your dependencies?Hack-along, live hacking of a vulnerable Node app https://github.com/snyk-labs/nodejs-goof, Vulnerabilities from both Open source and written code. Encouraged to download the application and hack along with us.Fixing the issues and an introduction to Snyk with a demo.Open questions.
Bring Code Quality and Security to your CI/CD pipeline
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
Workshop
Elena Vilchik
Elena Vilchik
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.