Forgive me for starting by telling you something you already know: open source is booming. It has become the de facto way of developing technology across every industry, used in an astonishing 99 per cent of software projects. No matter what you use technology for, you will be hard pushed to imagine a scenario where your data does not pass through at least one open source component. It’s no exaggeration to say the thriving global developer community is using open source to transform the way the world works, and it’s enabling rapid innovation.
But let’s cut to the chase. Despite skyrocketing growth, there is still a common misconception that open source is less secure than proprietary software because it’s open to anyone that wants to use it. Red Hat recently revealed that the biggest barrier to enterprise adoption of open source is perceived security issues.
In reality, this couldn’t be further from the truth. The open source community’s collective responsibility for developing and maintaining secure code makes it more securable than proprietary code, not less. With open source, not only are there more developers involved in identifying and fixing security issues, but they are eager to advertise their contributions and are incentivised to find and fix flaws before going live.
What is true, however, is that organisations can take a more progressive approach to integrating security into open source development, and increase their speed of innovation in the process.
Projects are only as secure as the software development lifecycle they are created in, but all too often security is bolted on to the end of the development process. Code is simply passed to security teams for checking, with predictably poor results. Software gets delayed and the pace of innovation slows. And the worst part is it’s so avoidable.
There’s only one way to fix the problem – infusing security into every single step of the development cycle. By integrating security into DevOps, you can effectively manage application security without slowing down business. And while there’s no one-size-fits-all approach to “DevSecOps”, there are sure-fire ways to make sure open source code is developed with security at the core.
Make your approach “developer-first”
Spoiler alert: it’s not simply a case of buying the right developer tools and calling it done. Effectively integrating security into the fabric of the business – not just into workflows – requires organisational change and a mindset shift. GitHub estimates software developers outnumber security professionals by a staggering 500:1, so some initial mistrust is inevitable when their worlds collide. But creating a culture of close collaboration can dramatically improve the speed and reliability of software development.
Take the perennial false positive problem, for example. False positives are the number one reason developers typically struggle to fix vulnerabilities while they build. But instead of developers wasting time fixing a slew of vulnerabilities that don’t actually exist, security experts can identify bugs and fix them during the cycle – and fixing issues in development is significantly less time intensive than fixing issues in production. IDC anticipates that by 2024 DecSecOps will drive half of all new applications in Asia-Pacific, with security testing introduced from the outset – but it’s concerning that half will not be.
Define a shared goal
Getting your security and DevOps teams working together effectively isn’t just a matter of when and how vulnerabilities are nipped in the bud. It’s also about prioritising the bugs that really matter. While the incidence of false positives can be reduced, the reality is they are very unlikely to be eliminated. But reducing them makes it significantly easier to identify and fix the “real” bugs that threaten software development. A common goal goes a long way to establishing a productive relationship.
Just as importantly, security professionals are critical to breaking the bad habits that no development process is immune to. A fresh look at development tools that security teams can trust is pivotal to reducing inefficiencies. If developers can’t trust their static analyses, there’s no incentive to fix any vulnerability, and the whole process falls down.
Make security everyone’s responsibility
Collaboration between security and DevOps teams can’t be skin deep, confined to issues and incidents only. For security to really become part of software development, it needs to be baked into day-to-day activity. That might simply be by integrating obligatory security checks into code reviews, or as deep as breaking down the traditional siloes of application security and CI/CD and building a unified workflow.
The bottom line is making security a community responsibility engrains it into the development process, which is critical to shipping more reliable software, more quickly. And that only spells good news for your organisation’s ability to innovate at speed.
