Dependencies & Packages
Security & Compliance
The course is part of this learning path
This course explains how to implement dependency management with Azure DevOps. It explores the strategies, tools, and methods used for creating and managing dependencies. First, you will learn what dependency management is and which packages are available for Azure DevOps. A practical demonstration then shows how to build a package. The course moves on to explore the strategies for dependency management, including versioning and componentization, and provides a demo that guides you through how to consume a package. Finally, you will learn about security and compliance, and watch a practical demonstration of WhiteSource Bolt.
By the end of this course, you should have a good understanding of how packages are managed within Azure DevOps and the implications of package management methodologies.
If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Explore what dependencies are
- Understand the various package types in Azure DevOps
- Manage packages in Azure DevOps through Artifacts
- Explore building software and creating dependencies
- Understand the strategies and methods for creating and managing dependencies
- Explore package security and compliance scanning options
- Individuals who want to learn more about Azure DevOps
- Individuals aiming to become Azure DevOps engineers
- Students preparing for Microsoft’s AZ-400 exam
To get the most from this course, you should have:
- Experience with version control and pushing changes into an Azure repo
- An Azure DevOps account
- Visual Studio installed if you want to follow along during the demos
- An understanding of Git and how to push code
Security and compliance. Trying to stay in control of dependencies that your project is consuming could be an overwhelming task if you had to do it manually. Luckily, there are numerous tools to enable good governance and security scanning of packages and can help you find and detect vulnerabilities or exploits.
If you're publishing packages to be consumed, security is important. If other companies, people or groups within your organization are going to trust software published by you it is important to ensure that only the people with the appropriate authority have the ability to publish packages. There are different roles for package feeds as shown here in this table.
In recent times, we have seen a number of companies in the news for a variety of reasons related to security and compliance. Often this has resulted in large fines or breach in security and customer information exposed. A company has a duty of care and responsibility to ensure their code is secure and adheres to licensing requirements.
Open source is becoming a much larger part of the IT world today. While it is great to be able to leverage the work done by the community or other vendors this comes with its own problems and at a cost.
You have to be aware of what you're using and any bugs or vulnerabilities that come along with that package. The code may even contain malicious content which you do not want to introduce into your organization.
While these bugs and vulnerabilities may be known, there may be no regular cadence to code release, meaning you can't be sure when or if it will be patched.
Some publicly available software comes along with certain license agreements. For instance, this package is not to be used for commercial use. In that situation you do not want to be caught out.
As we said earlier, trying to track and stay on top of licensing and code vulnerabilities is a challenge. There are tools you can use to integrate scanning for these things directly into your CI or CD pipelines. In addition, tools can be pointed at a repository and scan the artifacts of the repository directly. The benefit over scans done on the build pipeline is that sometimes vulnerabilities and exploits are found after code is released. If the code is only scanned during a build and an exploit was found months later, it could be missed.
One tool is WhiteSource Bolt. This tool will generate a report that can be found in the Pipeline section with three main areas:
- Security vulnerabilities which displays various levels of severity from low to medium and high.
- License Risks and Compliance shows a list of license types that are used and makes an assessment of risk.
- Outdated Libraries displays old versions of libraries. While these often have less immediate impact that can cause problems and introduce risks.
We're going to take a look at the WhiteSource Bolt demo. WhiteSource have a quick start template that will create a pipeline and allow us to test the product and have a look at the report it generates.
Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.