Technological transformation is increasingly becoming a competitive differentiator, with businesses across all sectors investing heavily in new platforms, tools, and frameworks. In response, open source has emerged as the most viable, cost-effective and leading-edge solution in enabling organisations to gain the edge in innovation.
No longer do individual businesses need to purchase or build all the software they need in-house. Instead, developers can now benefit from and build on the work of entire development communities, harnessing their collective power instead of starting from scratch. This is enabling countless new strands of innovation and increasing the speed to market for new products.
According to research, 69% of IT leaders deem open source as very important to an organisation’s overall enterprise infrastructure software plans. But software development wasn’t always done this way.
SEE ALSO: Cybersecurity trends for 2020
Changing purchasing patterns for enterprise software: from proprietary, to freemium, to open source
The last three decades have seen a huge change in software selection, purchasing, and usage. In the 1980s, MS-DOS hit the market and quickly emerged as the enterprise standard for computer technology. Soon after, Microsoft released Windows 1.0 and software companies like Oracle and SAP began making waves with their database products.
At that time CIOs were entirely responsible for the tools and software their company would use; technical users within the organisation were rarely consulted on their preferred platforms. The process of opting for a specific proprietary tool was extensive too. Each came with a hefty price tag, meaning the purchasing decision was carefully considered, tools were tested and re-tested, and it wasn’t uncommon for onboarding to take months or even longer.
This all changed with the introduction of freemium models in the early 2000s, as software became more open, accessible and easier to implement. CIOs remained involved in purchasing decisions but overall decision making shifted to operations leads. As a result, organisations began adopting new applications that promised to streamline processes, boost productivity and enhance experiences.
Fast-forward 10 years and the bottom-up decision-making models are now commonplace. Businesses are responding to increasing pressure to build and deliver software and services better and faster, by allowing developers and other technical users to take matters into their own hands. To meet ever-growing expectations, they required carte blanche access to tools that could help them automate the CI/CD pipeline, build and deploy apps at scale and solve new challenges – fast.
Free, open source software presented the “perfect” solution to this situation. Since it didn’t require licensing, developers could deploy it quickly without involving senior IT leadership and often, completely without their knowledge. Given developers’ growing clout, open source usage increasingly became an accepted norm, and DevOps teams are now regularly empowered to push the boundaries of innovation and propel digital transformation initiatives.
Securing open source secrets
Security teams recognise this shift in decision making, but more often than not are left on the outside looking in. In the drive to produce code faster, DevOps teams often fail to consult with security teams before adopting the latest, greatest open source tools. This can lead to insecure practices including embedding secrets, such as credentials for sensitive databases or cloud access keys, in applications and configuration files.
The risks associated with these embedded secrets are heightened by the push to share code outside of the organisation, as the sense of community around developers’ work increases. Sharing code brings important benefits, but it can expose secrets and other confidential information embedded in the code, leaving businesses vulnerable to attack. This may also be the case when developers re-using third-party code without sufficient scrutiny or attention to updates. In fact, 31 percent of organisations suspect or have verified a breach related to open source components in the last year. When selecting and using an open source tool, it is imperative that developers evaluate it for potential security issues, particularly the tool’s ability to handle secrets securely.
Unfortunately, most conventional security management solutions and practices are designed to support traditional software applications and development methodologies. They are far too slow and complex for the fast-paced world of open source software, microservices, containers, orchestrators and serverless technology. DevOps requires a fresh approach to security that mitigates risk and uncertainty without impairing velocity. Security leaders must look for ways to empower developers to use open source tools more securely.
Four ways to empower developers with open source secrets management
Many security teams are introducing open source secrets management to their development counterparts to help secure DevOps pipelines, and the technology is gaining particular traction in four key use cases:
Securing CI/CD pipelines
Popular automation and configuration tools require secrets to access protected resources like databases, SSH servers, and HTTPs services. Yet these secrets are often insecurely hard-coded or stored in configuration files or code. Security controls can remove hard-coded secrets from open source DevOps tools across the CI/CD pipeline, while providing full audit trails, policy-based role-based access control (RBAC) and secrets rotation.
SEE ALSO: Enterprise open source software is growing within innovative companies
Securing and authenticating containers
Containers have solved a lot of problems for DevOps and engineering teams by improving the portability and speed of applications. But their ephemeral nature makes it difficult to identify and determine access rights. A zero-trust approach is essential when reviewing container requests for secrets, in which containers are matched against their key attributes for authentication. Information can then be shared with them on a need-to-know basis.
Managing elastic and auto-scale environment secrets
Cloud providers offer auto-scaling capabilities to support elasticity and pay-as-you-grow economics. But the dynamic nature of cloud auto-scaling creates security management challenges for organisations. Usually, when a new host comes online, the owner of the host can manually set permissions, but this human interaction doesn’t scale. However, with the right authentication measures, the identity enrolment of new hosts can be automated.
Eliminating multi-cloud, multi-tool security islands
Secrets are typically maintained and administered separately, using different systems or ‘security islands’, which makes it difficult to share secrets and institute uniform security policies. In such cases, a central authentication system can be used to control and audit non-human access across leading tool stacks, container platforms, and cloud environments. This acts as a robust secrets management system to help streamline operations and improve compliance.
Open source secrets management allows developers to continue doing what they love without worrying about security. For organisations with expanding enterprise requirements, it represents a comprehensive solution towards securing secrets and other credentials in DevOps environments that sit within existing workflows.
The post How security keeps up when developers drive open source appeared first on JAXenter.
Source : JAXenter
