Securing with Secrets
Compliant Development Process
The course is part of this learning path
Configuration is an important aspect of determining an application’s behavior. Settings files often include sensitive information like passwords and API keys. In this course, we will look at how to protect that sensitive information while the app is being developed and when it is in production.
Azure’s App Configuration Service allows you to manage access to settings data and we will see how to use it within a .Net application. We will look at using Azure Key Vault in conjunction with App Configuration Service, and how to access Azure Key Vault directly from your application and from apps running in a container within a Kubernetes cluster.
Next, we look at the idea of shifting left security testing within your development process, and how we can automate security testing as part of implementing a compliant development process. Much of this will involve using extensions from the Azure marketplace within your DevOps build pipeline.
This course contains numerous demonstrations from the Azure platform so that you can get a first-hand look at the topics we will be covering. If you have any feedback relating to this course, please contact us at email@example.com.
- Learn about app configuration
- Run and deploy apps with the Azure App Configuration service
- Use Azure Key Vault to store secrets and certificates
- Access Key Vault directly from your apps, including those running within a Kubernetes cluster
- Create a compliant development process by integrating code analyzers, branch policies, quality gates, open-source library scanning, and automated penetration into a build pipeline
- Intermediate-level developers, DevOps engineers, and product managers
- Anyone interested in learning how to implement secure app configurations and development pipelines
To get the most out of this course, you should have some pre-existing knowledge of software development and of using Microsoft Azure.
To use WhiteSource Bolt in our build pipeline, first thing we need to do is add the extension into our Azure DevOps from the marketplace. So let's go and browse the marketplace and search for WhiteSource Bolt. Okay, got two options here. I'm gonna choose WhiteSource Bolt, which is free.
Obviously there are limitations to a free tool, and one of those limitations is the number of scans you can do per day, which is currently limited to five. My organization is already there in the Azure DevOps list. I'm just going to hit install. You can see there is an option for installing WhiteSource for on-premise Azure DevOps servers.
Okay, back to Azure DevOps and we can see now there is a WhiteSource Bolt menu item underneath pipelines. We'll go into there and just fill in some details to get the extension set up completely. Having done that, I will click the get started button, but all that's done is take us to the WhiteSource website where there is some useful information on how to get started, which is exactly what we're doing now. To use it, we need to include it in our pipeline.
I'll go back to the pipeline and just for simplicity, I'm going to remove the SonarCloud tasks and then search for the WhiteSource Bolt task and add it. We can leave the working directory blank, and under advanced settings, there the options to exclude folders or files or add extra folders to scan. So, I'll just click add to add the task. We don't need any inputs, and I will just give it a display name of scanning open source. Okay, let's save that with a comment. Yes, I should not have done that on the master branch. Nevermind, I'll just create a new branch for the commit. So, here's the build running, there's nothing really to see here in terms of what WhiteSource Bolt does, it all happens remotely, and it's just the end report that gets pushed back to Azure DevOps.
Once the pipeline has finished running, we go back to the WhiteSource Bolt menu item and the report is loaded. So, at the top of the report, we have a security summary where there's a vulnerability score. The score is that of the most vulnerable element in the report. It gives us a breakdown in terms of severity of all the vulnerabilities and also has an indication of when vulnerabilities were first logged. So, we can see some are more than 90 days old.
As this is pretty much just a boilerplate project, there's nothing much to see here. All the issues are with jQuery libraries being out of date. The next section, license risks and compliance, tells us what kind of open source licenses we have in our project. Apparently, WhiteSource Bolt does not know what risk we're at with the Azure SDK, that's interesting. Below licenses, we have a list of all the libraries that are outdated or that could be updated. 290 does seem a lot. And then at the very bottom, we have an inventory of all the libraries involved in the project. Wow, that just goes to show how much code you don't write when you're building an application.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.