Snyk Open Source

Welcome to this room, where you will accompany Jessica, an enthusiastic junior application security engineer, as she conquers open-source security dilemmas utilising Snyk (opens in new tab). Join forces with her and elevate your proficiency in securing modern software projects!

Learning Prerequisites

We recommend completing the DevSecOps path before diving into this room.

Learning Objectives

• Recognise open-source security risks and comprehend their implications on contemporary software projects
• Operate Snyk effectively to detect vulnerabilities
• Evaluate and classify identified vulnerabilities
• Apply appropriate remediation measures

Sign Up and Log In

Jessica is helping the development team onboard Snyk Open Source. She visited the IT department to ensure developers could log in to the platform using Single Sign-On (SSO) login, a secure authentication method companies use to enable employees and authorised users to access applications and services with just a single set of credentials. Instead of having separate logins for every application, SSO simplifies the sing-in experience by integrating all accounts under a centralised identity provider. 

She knows that SSO improves the user experience and reduces frustration among developers. She then returns to the development team to set up this new project on the platform, connecting it to Patch Corp's GitHub repository and performing an initial scan.

She visits the platform at https:/app.snyk.io/ (opens in new tab).

Note: You can create a free Snyk account by signing up with your GitHub account. This will integrate directly with the projects you are hosting on GitHub, and you can start scanning for vulnerabilities. 

Jessica then chose the integration method. She knows that the team is using GitHub to host their repositories. She connects Snyk to the code. 

She gives access to both private and public repositories. The development team has their primary repositories set to private visibility.

She then enables a few features she would like to demonstrate to the team, such as checking the pull request when a developer is pushing to GitHub.

The developers now all have a license and can access the dashboard to see all the projects they are working on. It is now time for Jessica to import the new project.

Note: You can clone the project to your own GitHub account from here (opens in new tab).

Import a New Project

Jessica clicks on Add projects in the top-right corner of the screen, then selects GitHub as the integration type.

She looks for the repository to be added.

She selects the repository and clicks on the green button at the top-right corner, Add selected repositories.

The project is now available on the dashboard. Jessica and the developers can see there are a few vulnerabilities. 

Jessica will analyse the results in a second, but she wants to ensure the developers also have this visibility from their IDE.

Helping the Developers Have Visibility Into Their IDE

As part of her mission to promote a shift-left security mindset among developers, Jessica focuses on integrating the Snyk integration on the IDE they use. The team is using Visual Studio Code. She helps them install the extension to streamline vulnerability detection and remediation within their IDE.

Note: Go to the extension tab on Visual Studio Code and type Snyk into the search bar. You can go ahead, install the extension and reload your IDE. A new icon should appear on the left sidebar. You will need to be authenticated before you start a new scan. If you're not using Visual Studio Code as an IDE, you can look at the documentation to install it on another IDE (opens in new tab). You then need to run the command npm install on your terminal to install all the dependencies and see the Snyk Open Source results.

Now that the development team has the integration set up, they have the same visibility on the vulnerabilities on the Snyk dashboard. 

Analyse Results From the Dashboard

Jessica is now looking at the results of the scan. She organises the results by severity level (high, medium, low), which allows her to prioritise critical issues first. She can explore individual entries to view additional details such as security information, an overview of the vulnerability, the affected files, and suggested remediations.

Jessica looks at one of the lodash vulnerabilities.

Analyse Results From the IDE

On the IDE, the developers can have all the details from a specific security vulnerability and better understand the context. One of the developers is asking Jessica for help understanding the vulnerabilities and which ones they should fix first.

Jessica sits down with the development team and looks at the results. She can see that they are using outdated packages with a few security vulnerabilities.

The developers are asking Jessica what the impact of a prototype pollution vulnerability in their codebase could be if it is not fixed.

Jessica explains that prototype pollution refers to a specific class of vulnerabilities found in JavaScript objects, mainly when dealing with prototypes. It happens with unintended modifications or additions to built-in object prototypes, leading to unexpected behaviour and security risks.

She first explains how JavaScript handles inheritance and prototypal chains to understand prototype pollution. When creating a new object, JavaScript uses the prototype chain to look for properties and methods. The prototype chain starts with the Object.prototype and continues upward until it finds the property or method requested.

She then shows the following example where prototype pollution might occur:

Modifying an object's __proto__ property allows us to inject new properties onto existing built-in prototypes, such as Array. We can potentially alter the functionality of core JavaScript features:

• Unpredictable behaviour: Modified prototypes may cause functions to behave differently than intended, leading to bugs and crashes.
• Data manipulation: Malicious actors can use prototype pollution to modify data stored in arrays or other structures, resulting in incorrect outputs or even data loss.
• Information disclosure: Attackers can exploit prototype pollution to gain access to sensitive information stored in affected variables or objects.
• Denial of Service (DoS): Attackers can create DoS attacks against vulnerable systems by causing applications to crash or malfunction.

To mitigate the risk of prototype pollution, developers should avoid modifying built-in prototypes and sanitise user input before assigning values to __proto__. Libraries and frameworks often have built-in protections against prototype pollution; keeping dependencies updated helps prevent vulnerabilities caused by this issue.

// Assuming global variable `Object.prototype.__proto__ = {}` exists
const pollutedObj = {
    __proto__: {
      // Adding a new property to Array.prototype
      length: 999,
    },
  };
const array = [];
array.__proto__ = pollutedObj;
console.log(Array.length); // Output: 999 instead of expected value

Note: You can do the Snyk Learn lesson (opens in new tab) on this vulnerability to learn more about Prototype Pollution. This vulnerable piece of code is also available in the repository that you can clone from here (opens in new tab).

The developers asked for more details on another vulnerability - directory traversal.

Jessica explains that a directory traversal is a type of web application vulnerability that allows an attacker to manipulate input data to access directories and files outside of the intended scope of the application. This is typically done by using special characters such as ../ to move up through the file system hierarchy. A successful directory traversal attack can lead to unauthorised access to sensitive information, such as source code, configuration files, or other applications running on the same server.

const express = require('express');
const path = require('path');
const fs = require('fs');
const app = express();
app.use(express.static(__dirname));

// VULNERABLE FUNCTION - SEND FILE WITH USER-SUPPLIED FILENAME
function sendFileWithUserSuppliedName(res, filePath) {
  const filename = req.query.filename; // User-supplied filename without validation
  const fullPath = path.join(__dirname, filePath, filename);
  
  fs.access(fullPath, fs.constants.F_OK, (err) => {
    if (!err) {
      res.sendFile(fullPath);
    } else {
      console.error(`File not found: ${filePath}`);
      res.status(404).send('File not found.');
    }
  });
}

app.get('/vulnerable', (req, res) => {
  const filePath = 'files';
  sendFileWithUserSuppliedName(res, filePath);
});

app.listen(3000, () => {
  console.log('Vulnerable app listening at http://localhost:3000');
});

In this example, an attacker could supply a specially crafted URL to traverse the directory structure and access restricted resources. For instance, requesting http://localhost:3000/vulnerable?filename=../../../etc/passwd would attempt to disclose the contents of the /etc/passwd file on Linux systems. A more secure approach involves validating the supplied filename against an allowlist of accepted values before constructing the final file path. 

Note: You can do the Snyk Learn lesson (opens in new tab) on this vulnerability to learn more about directory traversal. This vulnerable piece of code is also available in the repository that you can clone from here (opens in new tab).

Let's see how Jessica and the development team can fix these vulnerabilities.

Jessica explained to the developers that they could follow a few options to fix the vulnerabilities. First, they need to decide which one they should remediate first. She wants to communicate effectively with her fellow developers concerning vulnerability management and prioritisation. Her focus on addressing high-severity vulnerabilities in the upcoming sprint demonstrates a strategic approach to minimising risks and maximising resource efficiency. 

The reasoning behind focusing on high-severity vulnerabilities: High-severity vulnerabilities pose significant threats to the organisation, users, and stakeholders. These vulnerabilities typically allow attackers to compromise systems, steal sensitive data, or disrupt operations. Addressing high-severity vulnerabilities first ensures that the most dangerous weaknesses are eliminated, reducing the likelihood of a severe incident. 

Vulnerability Triage

Triage evaluates and categorises vulnerabilities according to their severity, impact, and likelihood of exploitation. Triaging vulnerabilities enables teams to allocate limited resources efficiently and make informed decisions about which vulnerabilities require immediate attention. 

Jessica explains a few best practices for vulnerability triage:

• Prioritise based on CVSS scores: The Common Vulnerability Scoring System (CVSS) provides standardised scoring metrics for assessing the severity of vulnerabilities. Teams should use CVSS scores to determine the relative importance of different vulnerabilities. 
• Consider the business context: Not every vulnerability poses an equal risk to the organisation. Factors such as the sensitivity of the data involved, regulatory compliance obligations, and the potential financial impact of a breach should inform triage decisions.
• Evaluate exploitability: Some vulnerabilities are more easily exploited than others. Teams should evaluate the ease with which an attacker could leverage a given vulnerability to mount an effective attack.
• Collaborate across disciplines: Effective vulnerability triage requires collaboration between multiple departments, including development, operations, and cyber security. Cross-disciplinary communication fosters shared understanding and consensus around triage priorities.

Jessica explained to the team that as the new Patch Chat App will expect user input, the development team should focus on vulnerabilities that would include this in its scope.

On the dashboard, Jessica shows the developers they can fix vulnerabilities by clicking on the green Fix this vulnerability button.

This will show available fixes for all vulnerabilities, and you can select the issues to fix.

Note: While you can apply bulk fixes on side projects, you must follow an organisation's CI/CD pipeline testing policy and workflow to avoid any significant breaking changes.

She scrolls down to Open a fix PR to open a pull request on GitHub, which looks like this. The PR has all the information about the vulnerability. 

Note: The pull request will be raised automatically if you follow this workflow. If you're not familiar with Git and version control concepts, we would recommend doing the Source Code Security room.

Addressing Vulnerabilities

The development team can fix all the vulnerabilities in bulk. However, Jessica said it is essential to balance the need to address high-severity vulnerabilities promptly while ensuring quality assurance and avoiding significant breaking changes, which involves careful planning and coordination among the developers. 

Jessica suggests a playbook to strike this delicate approach:

• Create a dedicated backlog: Establish a separate list of high-priority vulnerabilities requiring immediate attention. This will enable teams to track progress and manage expectations.
• Break down tasks into smaller chunks: Instead of attempting to resolve several high-severity vulnerabilities simultaneously via a single pull request, break each task into smaller, self-contained units. This makes testing easier and reduces the chances of introducing regressions.
• Implement continuous integration and delivery (CI/CD) pipelines: Use CI/CD tools to automate build, unit tests, and integration testing processes. Automated testing catches issues early in the development cycle, preventing defects from reaching production.
• Perform thorough manual testing: In addition to automated testing, conduct manual testing to verify that patches correct the identified vulnerabilities and don't introduce any unwanted side effects. Manual testing focuses on edge cases and scenarios not covered by automated tests.
• Conduct staged rollouts: Before deploying updates to production environments, perform staged rollouts in pre-production environments. Staged rollouts provide opportunities to detect and rectify issues before releasing software to end-users.
• Monitor performance after deployment: Continuously monitor the performance and stability of deployed software after release. If problems arise, quickly investigate and implement necessary corrections.
• Communicate openly and frequently: Keep team members updated on the progress, challenges encountered, and plans for resolution. Open lines of communication foster trust and cooperation, enabling teams to work together effectively.

Merging Changes and Pushing Remediations to Production

A well-functioning development team understands the importance of rigorous testing and validation procedures before pushing code into production. Maintaining a comprehensive suite of automated tests ensures that newly implemented features or bug fixes do not introduce regressions or compromise system stability. Jessica knows the development team has a test suite covering unit, integration, and functional tests. They also incorporated linters to detect anti-patterns or style violations earlier in the development cycle.

She also knows that when a pull request is submitted late on a Friday, the team must follow due process before merging it. Although tempting to expedite the procedure given the impending weekend, rushing through validations increases the likelihood of overlooked errors creeping into production systems. 

She agrees with the development team to review and execute the tests and checks on Monday morning. She knows that this approach instills confidence in both the engineering organisation and stakeholders regarding the reliability of their new features.

On Monday morning, Jessica was looking at the Snyk dashboard. She realised that a new vulnerability had been introduced in lodash@4.17.5 - the version recommended in the pull request raised on Friday.

She sits down with the development team and lets them know they have two potential scenarios:

• They can merge the pull request from Friday as it is, but they will need to raise another one.
• They can update the pull request to reflect this new vulnerability and fix it with only one change by updating to the latest version.

The developers make sure they have the correct version before pushing the changes. The checks are green on GitHub; they can merge the changes and get to the next step in their CI/CD pipeline.

If you want to understand more about the different steps involved in a software development lifecycle, we recommend doing the SDLC room.

Note: Start remediating some of the vulnerabilities in this project and try to decrease the number of high-severity vulnerabilities! Once you've fixed all the high-severity vulnerabilities, you can start tackling the other ones.

Jessica knows that integrating Snyk Open Source into the CI/CD pipeline will help the process be automated and streamlined. The development teams are using CircleCI and GitHub Actions. She is making sure to follow best practices to help ensure smooth operations, maintain security, and promote efficiency by:

• Integrating with the existing tools: Integrating an automated vulnerability scanning solution into existing toolchains is important to avoiding disruptions and ensuring adoption.
• Implementing automated fixes: If possible and after discussions with the dev team, enable auto-fix capabilities to apply patches for identified vulnerabilities for pre-prod environments.
• Establishing thresholds: Define acceptable vulnerability thresholds before triggering build failures. This approach avoids unnecessary delays caused by false positive findings.
• Monitoring test coverage: This is to minimise the chance of introducing vulnerable code into production environments.
• Keeping track of progress: Use dashboards and reports from Snyk to monitor the health of the projects over time. Tracking progress helps identify trends and areas requiring improvement.
• Collaborating effectively: Share Snyk scan results with relevant stakeholders, such as developers, security engineers, and product owners. 

CircleCI and Snyk Orb

Jessica looks at the Snyk documentation (opens in new tab) and sees that the tool integrates with CircleCI using a Snyk Orb. CircleCI enables users to easily create CI/CD workflows using a group of ready-to-use commands called Orbs that can be added to the configuration file. With a Snyk Orb, Jessica can quickly add Snyk scanning to the existing CI/CD workflow in order to test and monitor for open-source vulnerabilities. The results are then displayed from the CircleCI output view and can also be monitored on the Snyk dashboard.

Jessica installs it from the Orbs registry page. 

Snyk GitHub Actions

Jessica looks at the Snyk documentation (opens in new tab) and she sees that the tool integrates with GitHub Actions. She goes to the Actions tab on the repo and looks for the Snyk actions. She configures the Snyk Security one.

The YAML file is automatically populated. Jessica will need to make sure that the Snyk token is stored safely.

Bonus: Create a small CI/CD pipeline for this project and implement tools like CircleCI and GitHub actions to leverage security tools.

Jessica wants to configure continuous monitoring for Patch Corp's project. She wants to set up alerts, notifications, and reporting mechanisms that maintain awareness among the devs. Ongoing vigilance plays a crucial role in preserving application security.

Configuring Alert Thresholds

Jessica knows that establishing sensible alert thresholds ensures timely detection without overwhelming the developers with redundant or insignificant warnings. She considers these criteria:

• Severity: Configure separate triggers for distinct severity categories (critical, high, medium, low).
• Frequency: Define minimum intervals between consecutive alerts related to similar issues.
• Change rate: Establish baselines reflecting typical fluctuation in vulnerability counts, then set thresholds above these norms to flag anomalies effectively.

Periodically, Jessica will make sure to review and fine-tune threshold values based on historical trends and organisational needs.

Selecting Notification Channels

Jessica is selecting suitable notification channels to facilitate prompt action and minimise response times. Her options range from email and instant messaging platforms to ticketing systems and custom webhooks. Factors influencing channel selection include:

• Urgency: Opt for real-time communication means (Slack) when dealing with pressing matters requiring immediate attention.
• Integration capabilities: Leverage existing collaboration tools already adopted throughout the organisation, promoting consistency and familiarity.
• Audience preferences: Cater to personal inclinations by offering multiple avenues for receiving alerts, allowing individuals to choose methods aligning with their working styles.

Generating Informative Report

Jessica wants to create comprehensive yet digestible reports to enable the stakeholders to comprehend complex security landscapes quickly. She focuses on delivering valuable insights through visualisations, summaries, and trend analyses. Essential elements of effective reporting include:

• Executive summaries: Provide concise overviews highlighting salient findings, actions taken, and planned future steps.
• Trend analysis: Illustrate progression or regression patterns via line charts, bar graphs, or heatmaps.
• Risk prioritisation: Classify vulnerabilities according to severity, likelihood, and impact, guiding remediation efforts towards areas of highest concern.
• Comparisons: Compare current states against past performance metrics, elucidating advancements or shortcomings.

Alerting/Monitoring Through ChatOps

ChatOps refers to the practice of using real-time messaging platforms, such as Slack, Microsoft Teams, or others, to facilitate collaboration, streamline workflows, and improve operational efficiencies within technical teams, including security and DevOps teams.

Jessica explains the benefits for both teams:

• Enhanced collaboration: ChatOps promotes interaction between team members, allowing them to share knowledge, ideas, and insights in real-time, resulting in faster problem-solving, better decision-making, and improved overall productivity.
• Improved visibility: Team members have instant access to relevant information, status updates, and alerts. It helps everyone stay up-to-date with project developments, vulnerabilities, and other critical matters.
• Reduced response times: Real-time messaging platforms support quick and efficient communication, resulting in reduced incident response times and lower costs associated with fixing vulnerabilities.
• Increased transparency: It encourages transparent communication, helping to establish accountability and responsibility among team members.
• Better documentation: It facilitates the creation and maintenance of centralised documentation. Team members can easily search for past conversations, find answers to questions, and review essential discussions.
• Integrations and automation: Many modern messaging platforms offer integrations with various tools and services used by security and dev teams. Teams can integrate monitoring solutions, ticketing systems, and CI/CD tools with messaging platforms.
• Streamlined incident handling: It supports rapid incident detection and response. When a new issue arises, team members receive automatic notifications and can collaboratively diagnose and resolve the problem

Jessica decided to integrate Snyk into Slack, which is used within the development team so that they can have the alerts on a dedicated channel. She looks for the Snyk App on the Apps registry on Slack and reads the information on the Slack Snyk page to make sure it is compliant with the security policy they have in place in terms of permissions.

She then captures the channel ID from Slack and inputs it on the Snyk Dashboard.

Before finishing setting up the Snyk ChatBot integration, Jessica made sure to set the severity level to High and above. She considers this as best practice:

• Prioritising critical vulnerabilities: She ensures that only the most severe vulnerabilities are flagged by the team. 
• Avoid alert fatigue: This is when individuals become overwhelmed by excessive notifications, leading to decreased effectiveness in responding to genuine threats. Jessica minimises the number of false positives reported to her team.
• Preserving team focus: Team members can concentrate on resolving pressing issues without becoming bogged down by trivial concerns.
• Encouraging proactive behaviour: Jessica motivates the team to take a proactive stance towards security. The team becomes more vigilant about identifying potential weaknesses and taking action to mitigate risks.
• Promoting effective resource allocation: Jessica ensures that the team allocates its limited resources wisely. She directs the team's efforts toward tackling the most severe risks first and optimising the return on investment in terms of security improvements. 

The developer can now see the alerts coming through on the Slack channel.

Jessica wants to take some additional steps as best practices to enforce the process within the team's workflow.

Crafting Robust Policies

Jessica decides to craft an effective policy creation that will serve as the cornerstone of successful risk management initiatives. Here are some key aspects she is looking at:

• Defining scope: Jessica will need to clearly specify which projects, repositories, or technologies fall under the scope of established guidelines. Our example encompasses all public and private repositories managed by Patch Corp.
• Setting expectations: Jessica will outline mandatory procedures, standards, and restrictions concerning open-source usage. She will mandate automated vulnerability scanning using Snyk Open Source within their pipeline.
• Designating responsibilities: Jessica will need to assign clear roles and accountabilities for all involved parties, ensuring everyone understands their obligations. Jessica would assign specific duties to the devs, testers, and security engineers to ensure everyone plays a role in mitigating risks. Security is a shared responsibility in DevSecOps.
• Periodic assessment and updating: Jessica will regularly evaluate policies to keep them current and aligned with evolving industry best practices, based on new information, emerging trends, and lessons learned from previous incidents. 

Educational Initiatives

Jessica knows it is essential to have a strong roadmap of educational activities for her company:

• Onboarding modules: Jessica will introduce new team members to essential tenets, standard methodologies, and available resources. She thinks of creating an onboarding module covering the basics of vulnerability management, open-source licensing, and the importance of secure coding practices.
• Refresher courses: Jessica will periodically revisit core concepts to reinforce learning and tackle potential knowledge gaps arising from staff turnover or shifting job requirements. 
• Specialty workshops: Jessica will organise advanced sessions concentrating on specialised subject areas catering to varying skill levels and interests. She's thinking of hosting a workshop on advanced vulnerability analysis techniques, such as fuzzing and exploitation, to enhance the dev team's capabilities. 
• Interactive formats: Jessica knows that hands-on labs and gamified challenges are the best to encourage active participation among learners. 

Promoting Dialogue Among Diverse Departments

Jessica has some ideas in mind to streamline collaboration and communication:

• Sharing resources: Jessica will use their content management system to store and disseminate important security documents/policies
• Collaborative platforms: Jessica chose communication tools (like Slack) that accommodate both sync and async interactions.
• Standardised toolsets: Jessica will take part in discussions about tooling and platforms that will facilitate seamless information exchange, task tracking, and status monitoring to make sure that the security team will be using the same toolset.

What's Next for You

Now that you've gained some experience setting up Snyk Open Source on one project, you can start using it on your side projects or even securing open-source projects!