{{announcement.body}}
{{announcement.title}}

How Security Keeps Up When Developers Drive Open-Source

DZone 's Guide to

How Security Keeps Up When Developers Drive Open-Source

In this article, we discuss trends in enterprise software purchasing and how the mass adoption of open-source tools has often led to poor appsec.

· Security Zone ·
Free Resource

Open source is transforming software development. No longer do individual businesses need to purchase or build everything they need in-house. Instead, they can rely on a modern, interdependent ecosystem in which developers work together on mutually beneficial projects. This way, a single company doesn’t need to shoulder the entire development cost or have all the skills needed for the project.

But, it hasn’t always been this way.

The Enterprise Software Purchasing Shift: Proprietary to Freemium to Open Source

When it comes to software selection, purchasing, and usage, much has changed over the past three decades.

In the 1980s, MS-DOS hit the market, quickly becoming 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, the CIO called the shots on what software the company would use, rarely consulting technical users within the organization. Since each proprietary tool came with a hefty price tag, each purchasing decision was carefully considered, tools were tested and re-tested, and it wasn’t uncommon for onboarding to take months — or even longer.

With the introduction of freemium models in the early 2000s, software became more open, accessible, and easier to implement. While the CIO remained involved, decision making shifted to operations leads, and organizations began adopting new applications that promised to streamline processes, boost productivity, and enhance experiences.

Fast-forward 10 years and the top-down decision-making model was replaced by a bottom-up model. As organizations felt increasing pressure to build and deliver software and services better and faster, developers and other technical users began 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 was the “perfect” solution. Since it didn’t require licensing, developers could deploy it quickly without involving senior IT leadership (and, often, completely without their knowledge). And, given developers’ growing clout within organizations, open-source usage increasingly became an accepted norm, empowering DevOps teams to push the boundaries of innovation and propel digital transformation initiatives. It’s estimated that 78 percent of all enterprises use open-source software today.

You may also like: How To Secure Open Source Software.

The Open Source Security Challenge: Shortcuts for Handling Secrets Abound

Security teams recognize this shift in decision making but are often left on the outside looking in. In the drive to produce code faster, DevOps teams often do not consult with security teams before adopting the latest, greatest, open-source tools. This can lead to insecure practices such as:

  • Embedding secrets — such as credentials for sensitive databases or cloud access keys — in applications and configuration files. Fueled by the growing sense of community around developers’ work, the risks associated with embedded secrets are heightened by the push to share code outside of the organization. While sharing code is well-intended and brings important benefits, it may expose secrets and other confidential information embedded in code, leaving an organization vulnerable to attacks.
  • Re-using third-party code without sufficient scrutiny or attention to updates. In fact, 31 percent of organizations suspect or have verified a breach related to open-source components in the last year.
  • Selecting and using an open-source tool before evaluating 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 and are far too slow and complex for the fast-paced world of open-source software, microservices, containers, orchestrators, and serverless technology.

Security leaders understand DevOps requires a fresh approach to security that mitigates risk and uncertainty without impairing velocity. Now, security leaders are looking for ways to empower developers to use open-source tools more securely.

Four Ways to Empower Developers With Open-Source Secrets Management

CyberArk Conjur is an open-source security service for controlling privileged access to critical systems. It works to secure secrets (i.e., passwords, SSH keys, certificates, and API keys) used by non-human identities and users in CI/CD environments and across open source tools to DevOps teams to embed security into existing workflows.

Security teams are introducing open-source secrets management to their development counterparts and are gaining traction with four key use cases:

  1. Secure CI/CD pipelines. Popular automation and configuration tools like Jenkins, Ansible, Puppet, and Chef 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. CyberArk Conjur removes these 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.
  2. Secure and authenticate containers. Containers have solved a lot of problems for DevOps and engineering teams by improving portability and speed. But, their ephemeral nature makes it difficult to identify and determine access rights. CyberArk Conjur authenticates container requests for secrets with native container attributes and manages secrets with RBAC policy. 
  3. Manage 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 organizations. When a new host comes online, the owner of the host can manually set permissions, but this human interaction doesn’t scale. CyberArk Conjur automates the identity enrollment of new hosts.
  4. Eliminate multi-cloud, multi-tool security islands. Secrets are typically maintained and administered separately, using different systems (or “security islands”), which make it difficult to share secrets and institute uniform security policies. CyberArk Conjur centrally authenticates, controls and audits non-human access across leading tool stacks, container platforms, and cloud environments with robust secrets management to help streamline operations and improve compliance.


Further Reading

Topics:
security ,open source security ,api management ,secret keys ,ssh ,api ,devops ,jenkins ,ci/cd

Published at DZone with permission of John Walsh , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}