Securing with Secrets
Compliant Development Process
The course is part of these learning paths
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 firstname.lastname@example.org.
- 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.
Who doesn't like free stuff? Open-source libraries are great. They don't cost anything, most of the hard work has been done, you can even customize them so they work just how you want. I wouldn't go as far as saying you get what you pay for, but this is another example of no free lunches.
There are a couple of considerations to take into account when using open source libraries. The most important one is the fact that you may be introducing vulnerabilities into your code base. When your own product has security vulnerability, it typically applies just to your product. So a hacker with nefarious intentions has to find a vulnerability in your software and then they can only exploit your data.
In the case of open source libraries, once a vulnerability has been found, the potential impact can be widespread. Potentially every piece of code out there that relies on that open-source package is now subject to malevolent forces. Another consideration when using open source software is that not all open-source software licenses are the same. When most people think of open source they think of being able to download it, use it as much as they like, incorporate it into their code, modify, really just no limit to what you can do with it. While this may be the case for many open source products, it is definitely not the case for all.
There are some licenses that stipulate, if you make any changes or modification to the original, you must also make those changes open source as well. Or make software that uses the libraries also open source. The GNU GPL requires that when you use GPL-licensed software to make other software and release it to the public, the resulting software must be open-sourced with the same license. Bottom line is be aware of your license obligations. The whole open-source thing definitely seems like a potential minefield, especially in the context of automated DevOps pipelines.
Due to the widespread use of open-source libraries and the rapid adoption of DevOps processors, it was only a matter of time before someone saw a gap in the market to provide tools that will help you navigate the open-source library obstacles. Whitesource is a company that makes tools for scanning open source libraries for potential security vulnerabilities and versions to make sure you're up to date and informing you of your license obligations. Next, I wanna look at how to integrate Whitesource Bolt, the Azure DevOps variant of the Whitesource product.
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.