Cyberattacks are on the rise in the era of COVID-19 and cybersecurity has become paramount to arm business-critical applications. Furthermore, new regulations have emerged to protect personally identifiable information (PII). A new cybersecurity awareness feels quite apparent throughout the tech spectrum. As a result, security policies are poised to integrate more directly within the process of engineering and deploying applications.

Nonetheless, while DevSecOps feels necessary to implement at this critical hour, it does present challenges. Primarily of which is a significant cultural shift. Uniting security and development isn’t as easy as it sounds, especially when faced with rigid enterprise bureaucracy. Plus, how can an organization incentivize DevSecOps if developers fear security tools will slow down their workflows?

The DevSecOps panel at the recent KubeCon + CloudNativeCon North America 2020 brought together leaders in the DevSecOps arena to advise introducing a security-first mindset to DevOps. Dan Papandrea, field chief technologist at Sysdig, led this super-informative panel. It featured:

Emily Fox, DevOps Security Lead, NSA
Peter Bosch, Cisco
Sunil James, HPE
Christian Weichel, Gitpod
Nicolas Chaillan, U.S. Air Force
Below, I’ll cover some of the key insights garnered from the event. To summarize, the panel identified how policy-first tools and open source initiatives are placing security controls within IDEs and CI/CD pipelines. And what will it take to get everyone onboard? It appears that transparent tooling automation, making security adherence natural and a new wave of security-aware employees will be critical components in the future era of DevSecOps.

What is DevSecOps?
First off, to get a better picture, what exactly is DevSecOps? And why has it come about?

In a previous article, we defined DevSecOps with six traits: security automation, security culture, de-siloing IT, shifting security left and security as an enabler (not a stalling force).

The KubeCon panelists seemed to echo all of these points. Fox described DevSecOps as “a term used by organizations to ensure their DevOps approaches have a security-first mentality.” To her, this means placing security automation within workload environments.

DevSecOps is something new. For most organizations, security isn’t baked into the standard development processes—it historically hasn’t been the first priority, Chaillan said. DevSecOps is changing that, adding continuous monitoring, zero trust enforcement and reducing the overall attack surface.

The move toward continuous release is also an impetus for DevSecOps. “Our cadence of delivery has been quickened,” said James. All organizations now feel pressure to deliver value to customers rapidly. An interesting byproduct of building security-first, he said, is “the ability to create the consistency and speed with which you can actually offer these capabilities.”

Another cause for DevSecOps is the sheer imbalance in the workforce. On average, the number of developers far outweigh the number of security folks, noted Bosch. So, DevSecOps could scale security across an organization more effectively than human power could.

Bosch also is hopeful DevSecOps could put an end to time-consuming bureaucracies stalling an agile security process. “Developers used to write code and wait for free months to open a firewall.” This may have been standard operating procedure decades ago, but in the age of continuous everything, enterprises must evolve how they handle IT security policies. “By uniting security with developers, we bring speed, robustness, avoid OWASP issues, and build applications that better contribute to the bottom line,” he said.

Finally, embracing DevSecOps is a significant commitment. The combination of culture and technology is essential, noted Weichel. As we infuse security testing into CI/CD pipelines and make everything security-first, he said, we indeed undergo a cultural shift—it’s something that permeates everything.

Challenges in Implementation
Companies attempting to introduce DevSecOps may run into a few challenges, including instilling the culture, implementing regulatory compliance and finding the right blend of open source and propriety tools to get the job done.

Bosh is no stranger to sluggish enterprises and the systemic change required to introduce DevSecOps. In these environments, changing companywide antiquated processes may require executive sponsorship. “By and large, it’s mostly culture,” he said, yet acknowledged a vast divide between the two groups: “How do you convince security do get out of their comfort zone? And how do you convince developers to get out of theirs?”

There is also developer experience to consider: Developers often view security tools as limiting their ability to deliver code quickly. Perhaps the biggest challenge to overcome is improving the experience of working alongside new security policies. If new practices are causing more pain, instead of automating pain points away, DevSecOps could suffer.

Outside of team dynamics, there are also technical hurdles involved when introducing and enforcing legal regulatory requirements. “Getting any sort of compliance baked into CI/CD pipelines is a challenge,” said Fox. Part of the problem is that the tooling to enforce such requirements isn’t there yet. “Cloud-native is continually evolving and security is constantly playing catch up,” she noted. “It’s an ongoing challenge.”

Incentivizing the DevSecOps Culture
Employees need incentives to change established habits. With the above challenges in mind, how can organizations create incentives to adopt DevSecOps? Well, outside of monetary incentives or straight up demanding it, incentivizing that security culture could happen in a few different ways, the panelists noted.

To Fox, it’s about “making security transparent to the developers.” You want developers to quickly build and deploy secure applications without the need for intensive cybersecurity training. Thus, the tools and processes must be as transparent and usable as possible. DevSecOps is possible “if you make it second nature,” she said.

Another way to consider DevSecOps culture is the end performance. If customers are happy, this is a positive gauge. James said he has witnessed CIOs at a few organizations using customer satisfaction scores as a guiding light for not only the business but for security effectiveness well.

Bosch similarly stressed an indirect incentive about overall company performance. “Companies that really embrace DevSecOps leads to better code,” said Bosch. This leads to more robustness, higher speed, and better-operating enterprises. Co-building a thriving success could be ample incentive alone for those who have the whole team in mind.

It’s that time of the month again. Open source collaboration enabler Gitlab has pushed out 13.5, the latest update to the popular multitool environment for devops integration/management/code-sharing/whatever the user base has glommed in since last time.

Gitlab 13.5 now includes SAST – static application security testing – for iOS and Android code, alongside the integration of the MobSF framework. Gitllab notes in its blog post describing the release that this sits alongside the existing fuzz testing for Swift and Java, with the intention of enabling testing for more people earlier on in the pipeline.

Another focus this month is collaboration, with the introduction of Group Wikis to share ad hoc and structured project information across developer teams. Gitlab claimed this was the most upvoted feature request in the history of the product, which is easy to believe when you consider the popularity of the publications amongst the devops crowd.

Advertisement

Also added is Kubernetes cluster cost monitoring, based on Kubecost, to watch out for expensively multiplying entities; Gitpod Workspace integration for creating, managing and deploying prebuilt development environments; a timeline view for discussions; multi-file shareable Snippets; enhanced binary object management at deployment; and a host of other minor additions and maturations.

Developer reaction has been generally enthusiastic, especially towards the SAST integration for mobile apps and the improved support for app deployment. Twitter user and systems architect @rpadovani93 noted that: “With release 13.5, @gitlab will be able to host Generic Packages as artifacts. Combined with their CI/CD, you can finally build whatever you want and automatically release it. Lovely.”

It’s getting harder to keep track of “Git”-branded DevOps startups with ties to the Microsoft-owned GitHub open source software mothership.

Among the latest is Gitpod, which announced native integration with GitLab, the open-source DevOps platform. Gitpod also last week disclosed a seed funding round as it seeks to flesh out the expanding DevOps pipeline.

Along with GitHub Enterprise and GitLab, the cloud-focused developer also links via a browser extension to the Bitbucket, the web-based version control repository hosting service owned by Atlassian (NASDAQ: TEAM).

Gitpod said its native integration with GitLab’s user interface represents “the last missing piece” in the latter’s DevOps pipeline used by more than 100,000 organizations.

“Until now GitLab users would set up and maintain a single [development] environment on their local machines,” the Germany-based company said in a blog post. “It’s time to free engineers from wasting their time with such tedious tasks and apply the lessons learned from [continuous integration/continuous delivery] and infrastructure as code to dev environments.”

The next step is building an automated Gitpod configuration for GitLab’s source code, the company said, adding that the DevOps integration is now live on GitLab and will be part of a version update released scheduled for Oct. 22.

San Francisco-based GitLab, which offers a DevOps platform as a single application, currently has more than 175 partners integrating with cloud platforms, the Kubernetes cluster orchestrator and legacy DevOps workflows. The partner ecosystem includes Red Hat’s OpenShift container platform and VMware’s Tanzu application service.

Meanwhile, Gitpod announced a $3 million seed founding round spearheaded by Speedinvest along with Crane Venture Partners and Vertex Ventures.

“Gitpod’s first mover advantage and vibrant open source community enables developers today to treat development environments as automated, yet customizable, resources they can spin up whenever they need them and close down and forget about them when they are done with their task,” said Sven Efftinge, Gitpod’s co-founder and CEO.

It’s getting harder to keep track of “Git”-branded DevOps startups with ties to the Microsoft-owned GitHub open source software mothership.

Among the latest is Gitpod, which announced native integration with GitLab, the open-source DevOps platform. Gitpod also last week disclosed a seed funding round as it seeks to flesh out the expanding DevOps pipeline.

Along with GitHub Enterprise and GitLab, the cloud-focused developer also links via a browser extension to the Bitbucket, the web-based version control repository hosting service owned by Atlassian (NASDAQ: TEAM).

Gitpod said its native integration with GitLab’s user interface represents “the last missing piece” in the latter’s DevOps pipeline used by more than 100,000 organizations.

“Until now GitLab users would set up and maintain a single [development] environment on their local machines,” the Germany-based company said in a blog post. “It’s time to free engineers from wasting their time with such tedious tasks and apply the lessons learned from [continuous integration/continuous delivery] and infrastructure as code to dev environments.”

The next step is building an automated Gitpod configuration for GitLab’s source code, the company said, adding that the DevOps integration is now live on GitLab and will be part of a version update released scheduled for Oct. 22.

San Francisco-based GitLab, which offers a DevOps platform as a single application, currently has more than 175 partners integrating with cloud platforms, the Kubernetes cluster orchestrator and legacy DevOps workflows. The partner ecosystem includes Red Hat’s OpenShift container platform and VMware’s Tanzu application service.

Meanwhile, Gitpod announced a $3 million seed founding round spearheaded by Speedinvest along with Crane Venture Partners and Vertex Ventures.

“Gitpod’s first mover advantage and vibrant open source community enables developers today to treat development environments as automated, yet customizable, resources they can spin up whenever they need them and close down and forget about them when they are done with their task,” said Sven Efftinge, Gitpod’s co-founder and CEO.

The Gitpod platform treats a version control system as the canonical source of truth from which it then automates everything a developer needs to start coding, including the integrated development environment (IDE), plugins, compilers, build tools, code generators, databases and application servers.

Fresh off raising an additional $3 million in funding, Gitpod CEO Sven Efftinge said instead of wasting a half an hour or more waiting for a bunch of libraries and tools to get installed, a developer can click a button that allows them to begin coding within a few minutes.

With the next release of GitLab, developers will also be able to connect their self-managed installation of GitLab to gitpod.io, which is a capability through which multiple git repositories can be registered. In addition, it’s possible to self-host Gitpod on a Kubernetes cluster in a way that integrates with GitLab or install the GitLab VS Code Extension in Gitpod to interact with GitLab.

Efftinge said Gitpod provides DevOps teams with a tool to automate the setting up of development environments across any Git repository that is equivalent to the Codespaces tool that GitHub recently made available. Rather than having that capability for only one repository, Efftinge noted most developers work on projects spanning multiple types of repositories.

By automating that process of setting up development environments it also become easier to align them with production environments. One of the reasons why code doesn’t work in a production environment when it is first deployed is because the local development environment has been manually configured in a way that doesn’t accurately reflect the production environment. That issue becomes even more problematic when developers are working on multiple projects involving, for example, separate microservices constructed using different repositories that might not even run in the same production environment. Collaboration also becomes easier when the members of the teams have standardized on the same instance of a local desktop environment.

Gitpod, formerly TypeFox, collaborated with Google, Ericsson, Arm and Red Hat to develop the open source Eclipse Theia project, which provides a foundation for building IDEs in the cloud using TypeScript, CSS and HTML. Theia, now being advanced under the auspices of the Eclipse Foundation, consists of a front end running in a browser or in the local desktop application and a back end running on any host. Both communicate through JSON RPC over WebSockets. Gitpod leveraged that project to build its own cloud-based service in addition to the core open source project.

In the wake of the COVID-19 pandemic, there’s naturally a lot more focus on automation and developer productivity. Most developers will be working from home for the foreseeable future to help combat the spread of the virus. Of course, most developers have been writing code outside the office for years. The challenge now is enabling teams of developers to develop applications as efficiently as possible regardless of where they are located. Eliminating inefficient manual tasks such as maintaining development environments is emerging as a significant step in that direction.