Computer Security: SecDevOps Tips

It should be common knowledge among software developers that writing software with as few weaknesses, vulnerabilities and flaws as possible is the most cost-efficient solution. Spotting them as early as possible, ideally already in the conception and design phase, spares the larger expenses later on of patching, upgrading or putting in place mitigation measures. On the other hand, why bother? It is a fun fact that software is one of two products worldwide where the costs of their flaws, of them not working, of them needing fixing, must be borne by the end user (the other product is drugs).

For CERN, however, the costs of good early programming practices or late fixing have to be paid anyhow: either by training software developers to produce neat applications and spend hours reviewing their products, or by investing in service managers and their time to fix development snafus afterwards. Good and secure development and operation ("SecDevOps") practices also have the advantage of reducing the attack sphere against the Organization since fewer bugs and fewer vulnerabilities are left to be exploited by the malicious evil. This undoubtedly improves our defence and protection.

Therefore, in order to catch blunders early, four great tools are at your fingertips - whether you happen to be a programmer, developer, webmaster or IT service manager:

  • Training (of course!): The more expert you are in your field, the more knowledgeable you are in the security pitfalls of your software stack, the easier it is for you to avoid mistakes, avoid introducing flaws and architect sound and proper applications. The CERN Learning Management System provides you with the appropriate courses - courses that just became mandatory for "all architects, software programmers, and developers of High-Risk Applications";
  • Guidelines: A series of so-called "Security Principles" have been published as an aide-memoire to be imperatively followed to make your software application, your "containers" and virtual machines, your server's operating system and your web application as secure as possible. Surely(!), there are more comprehensive and wider standards available. Actually, there is a cacophony of them out there. But the beauty of these Security Principles is that they are short, contain the basics and can and must (as per the Subsidiary Rules) be easily applied;
  • Tools: While there is a plethora of tools at your fingertips that allow you to spot problems and areas for improvement, the most efficient ones have been enabled in CERN's GitLab instance: "Secret Detection" and "Static Application Security Testing". Running these in your integration pipeline provides a quick overview of how "good" your code really is. And those are only two of GitLab's offerings to you for writing and deploying solid and perfect code. So why not take advantage of them?
  • Reviews: Having a second pair of eyes prior to programming, both during the conception, architecting and design phase, and right before deployment, is surely helpful. Getting the basic building blocks right, ensuring the aforementioned principles are applied and trying to identify areas for improvement. The Computer Security Office provides you with the right expertise to have your code or service reviewed. Actually, this is mandatory, too, for "all High-Risk Applications, IT Services, Projects, or Purchases with a software component intended to be deployed or already running at CERN".

So, everything is in place. Now it's up to you whether you choose to invest in yourself and further improve your skills, expertise and magic when writing secure code − for your benefit and that of CERN - or be ignorant or lazy and have the costs borne by IT service managers, the Computer Security Office and the Organization as a whole. Surely - no more tips needed here − you know what the right choice is.

/Public Release. This material from the originating organization/author(s) might be of the point-in-time nature, and edited for clarity, style and length. Mirage.News does not take institutional positions or sides, and all views, positions, and conclusions expressed herein are solely those of the author(s).View in full here.