Sometimes it feels like I’m pushing too much with security and software development, but then you prove me wrong.
Recently, we have run a survey among our customers. We asked about their concerns around software development.
Here are the top 4 answers:
From whatever angle we are looking at it, security returns. If we shut the front door, it will reappear through the rear entry.
I’m not talking about your skills. I’m talking about the fact that most GitHub code (typically 80-90%, and 65% for Java) contains some open source packages.
Any of those packages can be accessed by practically anyone, they need to be maintained, and there are PRs created by people which need to be reviewed. And as useful as those packages are, each of them can be the one source of vulnerability in your software.
That’s why “Secure dependencies” scored so high in our response list.
But there’s another side to this coin – open source software you create and publish also needs to be secured.
I don’t suppose you’d want to author a package that causes problems for anyone out there.
So, let’s talk about securing code in GitHub.
This won’t be a technical tutorial on what features to use – there are some good ones out there already. A link to them you can find at the end of this article, along with some useful resources.
But let’s clear up one thing first.
You might worry that testing your software earlier in development will delay the release. It’s easy to imagine that an endless supply of errors will stall your build.
Except it might not need to. In fact, you might even save time.
By doing tests early on, you gain at least two things:
Checking the product as you go, helps you to avoid the situation where 10 months later someone looks at a piece of code written by someone else and spends days trying to figure out what on Earth went on there.
But ultimately, it comes down to protecting your business.
If you use code written by someone else, you need to make sure it doesn’t introduce any vulnerabilities, or you risk a data leak further down the line.
To avoid it, you need to take into account the entire software supply chain:
It goes back to the old truth I may have mentioned before.
Security is everyone’s business.
Before, I talked about it in the context of users and IT. But it also applies to development.
Secure coding is not just the responsibility of developers. And it’s not just the responsibility of testers, nor your security team. It’s everyone’s responsibility.
There is no room for silos in security. It has to be a shared effort.
And yet, typically, by the time security is considered in development, it’s very late in the process, making issues more time-consuming and costly to fix. In their economic impact study, NIST estimated that improved testing at the development stage could reduce losses due to flawed software by half.
(If you don’t know them, NIST (National Institute of Standards and Technology) issues benchmark standards for the industry to help technology businesses provide the best possible solutions.)
As government entities start to recognize the importance of secure coding, the vendors are also working to make developers’ lives easier, and their code more secure.
GitHub is one of them.
Tips from GitHub on how to secure your code
Remember when I said that GitHub is likely the future?
The signs are all around us. Microsoft has developed an entire process for securing GitHub code, and more features are in progress.
Microsoft Build last May saw the announcement of the public preview for Azure Security Center integration with GitHub actions. Check out the video here.
It’s one way of getting your security teams involved with the development process and addressing issues before they happen.
As for GitHub itself, they also have an entire roadmap full of security-oriented features.
The fact that GitHub heads in the same direction signals that Microsoft is committed to making it the tool of choice for code development (no insider info, just my interpretation of the roadmap).
There are plenty more security-related updates planned but also features for the cloud and specifically for GitHub Enterprise, indicating that DevSecOps in GitHub is on its way to becoming a commodity.
For example, an upcoming feature will introduce moderation to implementing changes.
Given that, as I noted at the beginning of this article, most projects rely on open source code, adding a precaution that limits the risk of malicious changes being introduced is a great step towards building more secure products.
This is good news for you because it means that protecting your applications will be much easier in the future. Eventually, secure coding will be built into the entire development stack. But until then, it is on you to protect your code at the source.
To get started, check out this video tutorial by my colleague and MVP, Daniel Krzyczkowski.
Deploy and configure Azure infrastructure using Azure DevOps
As promised, here are some more technical guides and resources for you:
If you have any questions, feel free to get in touch.
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s t...
Sometimes it feels like I'm pushing too much with security and software development, but then you prove me wrong. Rec...