The other day I had a discussion about whether source code is more secure when hidden out of sight — a valid discussion point that sometimes comes up. So, I thought I'd write a little opinionated post on why it is both.
And without further suspense, it is as simple as that. Because it depends. It depends on project maintenance, processes around it, and project maturity.
And this depends has proven itself in real life over the years. We can just look at the former closed-source giants, like Microsoft, which has had countless security breaches over the years, Apple and other friends with a heavy usage of closed source. While open-source software also has its daily bugs and security breaches, just like the weekly security patches and zero-day issues in Closed software that arrives in a never ending stream.
So the sad outcome is that a skilled attacker will find your bugs (vulnerabilities) regardless of code visibility. Maybe, just maybe, you can delay the finding by obscurity. But it will find you in the end if the project is interesting enough for someone to put time and effort into.
And, if the argument still seems to ring true after pondering this, why the heck is every piece of software we are currently running and basing our life's on running on open source as a base and dependency? Why has the European Union accepted it as a key for their digital strategy? Why has the White House listed open source as a must in their Cyber Security agenda if it's so unsecure? Why has big tech adopted it so hard? We might be nuts or...
Or, because the visibility of the code has proven itself not to matter as much as we might think.
If so, what can we REALLY do to improve security in a meaningful way in our open and closed projects?
A lot!! Really! Much more than we are doing at this moment. This is where the focus should go if we want REAL secure code. Not into the development model itself. Into securing and improving the system
And this is much easier now than just a few years ago. The software security world has matured after the latest years of big breaches, and a lot of former expensive or rare tooling has arrived.
Humans make mistakes. Make it easy to do it right and hard to do it wrong. Which means among other things automating
Here are some things you could do tomorrow in your projects, no intention means to be complete. I would almost bet that 9 out 10 of you who are reading this are not doing them all (including myself).
- Automation of checks mistakenly committed of configuration, secrets, IPs, and passwords in commits like gitleaks.
- Automation of checks for supply chain security vulnerabilities (third-party dependencies) with tools like OWASP's tools, Dependabot, Renovated.
- Automation of Static Application Security Testing (SAST) to find insecure code problems.
- Automation of Dynamic Application Security Testing (DAST) to find vulnerabilities.
- Automation of Software Component Analysis (SCA) to focus on third-party dependencies.
- Look over write access to projects.
- Clearly defined processes for code reviews and size of merge request.
- Plan and accept ongoing maintenance to regularly fix issues as they will change weekly.
- Minimizing the container images
- Make it easy and secure and encouragable to report security issues for outsiders and users.
Outside activities:
- Pen test bigger releases.
- Arrange a community Pen test invited hackday with prizes. Break the solutions and find vulnerabilities.
And so on, and so on...
Compare an open code base having all of the above steps in place, with documentation in place about the steps taken, or a closed-source base with no other docs "We have rigid security analysis process (trust us)". Who would you trust has the most security vulnerabilities? Whom would you or I as the end user trust? Whom should the end user trust? I know whom I would bet on.
Why we in the Public Sector should foster trust and transparency whenever we can
I honestly and truly believe that we who work in the Public Sector or similar tax payed jobs should have our goals on reaching our end users. For us in the digitalization services, that might be by means of Open Source, Open Data, good services and such. It has been proven again and again that it can not only help and give our Public Sector colleagues, but we can also receive trust from our real users—the citizens and part of that is we as humans and we as organizations should just admit that we sometimes write crappy solutions - I create bad solutions every day, and so do you and everyone else ( and other days we do it just perfectly). We miss a few things, we sometimes make the wrong decisions, miss some facts and we need improvements. While doing our best to avoid them, we should still acknowledge that we will make these mistakes at times.
This is version 0.9 ... it will contains bugs, but belive us, we are doing our best to improve upon it; We are still proud as **** of it and it is really usable - use it and please report the bugs!!. It will be maintained until archived
TL;DR
A bug is a bug is a bug. And while we can't avoid them, we can diminish them with good processes and tools. That is and should be the focus. Regardless of the development model. We in the Public Sector have an extra responsibility to be transparent.
Open Source and Closed Source has already proven itself in our global infrastructure. Don't fall for arguments that one code base is safer or more unsecure due the Source visibilty itself. Instead focus on what really means something regarding security, like security quality actions, reviews and system runtime security actions.
Links
https://en.wikipedia.org/wiki/Security_through_obscurity
http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf - The National Institute of Standards and Technology (NIST) in the United States recommends against this practice: "System security should not depend on the secrecy of the implementation or its components.
ISO27001 - I think some misunderstandings come from this, but read the answer here. https://security.stackexchange.com/questions/221644/is-the-iso-iec-27001-standard-incompatible-with-free-open-source-software
Top comments (2)
This seems to be a perennial topic in our world 😁
There are examples where open source has not provided the 'many eyes' and 'many hands' benefits to security that was hoped for (openssh being a recent fail), and although there are a number of good practices which reduce risk in both open and closed source models (as you clearly list out), each of these requires time and effort to put in place and maintain - cost which is often traded off against other interests such as: a commercial drive to be first to market and get investment returns (sometimes knowing it will crash and burn, but not caring); a desire to promote oneself as a productive developer (hire me, I'm a 10x dev!); a desire to quickly solve a problem and move on (hacked together code).
Thus I find the ethos of a group of people creating and maintaining software to be important in trusting them to get risk management / security right - my rule of thumb: software created without much care for our craft, skill and engineering professionalism is going to have issues, so actively manage the risk if you choose to use it!
I love your work man !! Seriously. This was so breath-taking and amazing !!
Kudos to good work !!