Sometimes it feels like we're pushing too much with security and software development, but then you prove us wrong.Recently, we have run a survey among our customers. We asked about their concerns around software development.Here are the top 4 answers:
- Secure dependencies
- Secure code
- Secure secrets
- Secure DevOps
From whatever angle we are looking at it, security returns. If we shut the front door, it will reappear through the rear entry.
Is your code really flawed?
We're not talking about your skills. We're talking about the fact that most GitHub code (typically 80-90%, and 65% for Java) contains some open source packages.
The problem? No, it isn't in the fact that it is open source.
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 on our response list.But there's another side to this coin - open source software you create and publish also needs to be secured.We 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.
Why bother with secure coding in GitHub?
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:
- You eliminate any problems that can hold you up further down the line.
- You won't have any unpleasant surprises using code written by someone else.
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:
- development
- testing
- update stages
It goes back to the old truth we may have mentioned before.Security is everyone's business. Before, we 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 recognise 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
What is the future of secure coding in GitHub?
Remember when we 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 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 our interpretation of the roadmap).
Security-related updates in GitHub
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 we 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.
Start securing your code now!
As promised, here are some more technical guides and resources for you:
- Secure software supply chain with GitHub security features - Daniel Krzyczkowski
- Securing your GitHub project - Marcin Hoppe
- Achieving DevSecOps maturity with a developer-first, community-driven approach - GitHub
- GitHub security features
- Enabling resilient DevOps practices with code to cloud automation - Microsoft Azure
- Azure Policy Compliance Scan Action for GitHub Workflows is in public preview
- Kickstart collaborative DevSecOps practices with GitHub and Azure
- Secret scanning partner program - GitHub
Author
