How can developers integrate security concerns and innovation in today’s threat environment? In this article, James Read explains that, in spite of its free and transparent nature, open source is uniquely positioned to face the threats of today’s security concerns.

The combination of today’s threat environment with the constant demand for innovation is putting extreme stress on businesses of all sizes across every industry, from developer to CIO. This pressure to innovate continues to grow, which leaves organizations paralyzed when confronted with the need for security, risk management, and their compliance goals. Security is often seen as a checkbox: an audit, a review, something that is bolted onto the delivery pipeline. This article will touch on how this implementation of security can stifle innovation. The technologists in these organizations, now used to looking to Open Source community for innovation, are looking again at how Open Source can help them break this deadlock and re-implement security in a way that balances the needs of both sides.

Security implementation is contextual; security will literally mean different things to different people in an organization. For a systems administrator, security often means implementing firewall rules and logging systems before making a system “go-live”. However, this is just the most basic example of security being considered at the end of a delivery pipeline. Quite literally, the last step in getting a system into production will be a security audit. While you can surely recount an example of this in your own organization (especially where the security audit has caused delays or a backtrack in the delivery of a system) this is still just one narrow aspect of a much wider security concern.

SEE ALSO: Open source: Less talk, more work

Organizations are starting to realize that being innovative means being agile. This agility has started to disrupt the way security is implemented too. “DevSecOps” is a term that makes some of us cringe. But by integrating the security practice into the feedback loop and delivery pipeline, it brings systems administrators and developers together during the project, not just at the end. To a developer working in isolation, they may mistakenly leave common security concerns until the end, with logging systems, user permissions and code assurances left far down the feature list. However, higher level security concerns cannot successfully be left until the very last moment without severe penalties on the delivery timeline.

The strong relationship between open source and security

It’s important to realize what I mean by this statement. I’m not saying that Open Source software is just more secure than closed source software. Nor am I implying that implementing effective security in an organization just relies on the selection of software. Security is not just a technology problem.

However, when the source code is out there in the open, developers, systems administrators, auditors and many others benefit from the inherent way that the software is developed. I’d like to look at the people in our organization now, and see how they’d be better with Open Source in their challenges to implement security at scale.

Let’s go back to our system administrator and consider how Open Source changes the way they work. Frequently just keeping systems alive in production environments, the IT organization has to support large and complex systems from a multitude of vendors. Some of this might be legacy software, but all of them have different approaches to security. Our system administrators are hampered by using lots of different patching and update mechanisms and keeping old software on specific versions. Although Linux is the open source operating system, it is often the IT foundation in regulated and sensitive industries due to its ability to manage security at scale for system administrators. Everything from the operating system, frameworks, libraries, and application dependencies are all delivered from one update mechanism that can be traced from executable all the way to the original source code.

While system administrators are not expected to be able to read through source code, this approach to putting everything in the open also helps developers, auditors and security professionals alike. The closed source approach to software development can be likened to the expression “security by obscurity”. Closed source software development is like a baker who tries to hide their ingredients and methods that make up the prized cake recipe, for fear that a competitor may get the secrets. While this seems logical, in principle, if we continue to use this metaphor for security, then our baker is trying to hide these secrets in a persistent cake competition, where everyone else is an expert baker and the cost of the secrets being found out is catastrophic, and the prize for the finder is considerable.

SEE ALSO: Why enterprises are flocking to open source

We know that in today’s tech landscape, the threats are persistent, sophisticated and often targeted. Keeping the source code closed doesn’t help us combat these threats. Keeping the code open allows these same developers to spot each other’s mistakes sooner. Often, they will contribute a fix. Auditors get the guarantees that the software that they’re running is genuinely made up from code that has been examined. Security professionals collaborate together to build better and more secure software before it even gets to a production server.

It’s important to acknowledge that open source software doesn’t pretend to be immune to security vulnerabilities either. HeartBleed, ShellShock and Drown are all serious vulnerabilities in open source software. However, these vulnerabilities demonstrate how the community works together to actively fix issues. These issues can be traced way faster than with closed source software, and the community will promote those vulnerabilities and the patches available to fix them. Linux and other popular open source software have an excellent security reputation. This is, in part, because its development model is not hampered by vendor secrets, limited security budgets, or lack of eyes on the code.

This goes to show how the open source development model can help operationalize and streamline security implementation across multiple roles. However, as I mentioned at the beginning of the article, security is certainly not just a technology problem.

Instead, information security must adapt to the ever-changing and increasingly complex threat landscape. Whether it’s providing customers and partners with access to certain systems and data, allowing employees to use their own smartphones and laptops, using applications from Software-as-a-Service (SaaS) vendors, taking advantage of pay-as-you-go utility pricing models from public cloud providers, or sharing information assets with authorized third parties, there is no longer a single perimeter. Nowadays, organizations require an IT security strategy that runs deeper and is more multifaceted than what we have seen before.

Red Hat

Red Hat offers a tested, supported portfolio of stable open source infrastructure and application development solutions for enterprise adoption of emerging technology. With Red Hat products and services, organizations can take advantage of security built into each phase of the application lifecycle.

However, Red Hat’s attitude towards security is far broader and deeper than just investing in product technologies. Helping customers operate secure environments and processes also means having ongoing expertise and direct involvement in upstream projects, implementing reproducible build and testing systems, delivering packages securely, and responding quickly and effectively to vulnerabilities, specifically through our Customer Portal.