devopsy.kinsta.cloud

Category: Blogs

How to Eliminate Incident Inefficiencies
In today’s complex, dynamic IT environments, the proliferation of disparate IT Ops, NOC, DevOps and SRE teams and tools is a given – and usually considered a necessity. This leads to the inevitable truth that when an incident happens, often the biggest challenge is collaborating between these teams to understand what happened and resolve the issue. Inefficiencies suffered during this critical stage can have huge impacts on how much each incident costs the business.

I recently sat down (virtually) with Sid Roy, VP of client services at Scicom, to get a deeper understanding of how IT leaders can more effectively size up these inefficiencies and eliminate them.

The Costs of IT Incidents

When asked what a minute of downtime costs, analysts and vendors may provide different answers – but they are more or less aligned around the same order of magnitude – several thousands of dollars per minute. And with an average of five major incidents a month and an average time of six hours for resolution, this easily amounts to millions of dollars a year.

The three key drivers of these costs are:

Staffing and team member costs: This includes full-time employees (FTEs), consultants, and overhead when other teams are pulled in to deal with the incident. For many organizations, this can include offshore incident response teams.

The direct and indirect costs of an IT incident: This includes your infrastructure or capital expenditures like software licenses for monitoring, log and event management, notification, ticketing, collaboration, etc.

The business impact of an IT incident: This is one of the most challenging and unpredictable variable costs to calculate or manage, and is often the highest of all three drivers. It includes revenue loss/delay or reduction due to a major incident, and the profit or loss due to brand or goodwill impact. It also includes inefficiencies suffered by other parts of the business when critical services they depend on are degraded or unavailable.

Fragmented Teams Magnify the Challenge

The incident volume, complexity and throughput obviously affect the number of people and amount of time needed to deal with them and often drive more indirect costs as needed resources pile up. To save on these millions of dollars of costs, you need to be able to collaborate and lower MTTR. As mentioned above, this becomes a challenge in agile IT environments. To help streamline operations, teams need to start asking and answering several key questions:
- Do you have an up-to-date map of your critical services?
- Are they prioritized by business criticality (revenue, number of customers, other supported services in the supply chain)?
- What are the upstream and downstream dependencies of these applications?
- Have you identified the major infrastructure and application elements in your environment?
- Are you aligned with the owners of these systems?
- Do you have real-time knowledge of changes being done to the infrastructure and applications?
- Do you have monitoring gaps?
- Which monitoring tools provide you with the best value?
Answering these questions involves overcoming fragmentation across teams of people, processes and tools – essentially integrating ITSM and ITOM to enjoy the benefits of contextual full-stack visibility and streamlined processes within the organization.

The Right Combination for Incident Response

What is the right combination of people, processes and tools we just discussed? Here are the two main guidelines:
- Set up a major incident management team – ideally, from your existing staff. This team includes three vital roles:
  - The incident manager/incident response commander. This is a designated role in charge of declaring a major incident and taking ownership of it. Their job is to, essentially, stop the bleeding of revenue and costs.
  - The NOC/monitoring team. This is your front line defense. When things go bump in the night or boom in the day, they’re the ones picking it up with their “eyes on the glass” – 24/7. And, they’re in charge of reporting and creating full situational awareness for the incident command through bidirectional communications.
  - The production support team. This team actually effects the required changes and executes the remediating action.
- Deploy event correlation and automation tools to enable the incident management team. These tools are key, allowing your team to perform the required actions.
  - First, correlate the alerts created by your monitoring and observability tools into a drastically reduced number of high-level, insight-rich incidents by using machine learning and artificial intelligence (ML/AI). Add context to these incidents by ingesting and understanding topology sources, as well. This creates the necessary full-stack visibility and situational awareness.
  - Then, use ML and AI to determine the root cause of these incidents, including correlating them with data streams from your change tools: CI/CD, orchestration, change management and auditing to identify whether any changes in your environment caused these incidents.
  - Finally, automate as many processes as you can to free your IT Ops team from manual, time-consuming tasks. By integrating with collaboration tools, you can also enable the above-mentioned bidirectional communications.
March 11, 2021
The Importance of Incorporating DesignOps Into DevOps

Design is a critical software project element that often goes unnoticed by those writing code. After all, coders and implementers tend to take the design process for granted and leave the look and feel of applications to the designers. In the days of waterfall based development, design was one of the first steps in the development sequence of creating a new application. However, with Agile and DevOps development practices, design became disconnected from the overall process.

“If you look at the full spectrum of AppDev, it becomes obvious that there are many elements that should be part of DevOps. Take, for example, cyber – today, there is a movement to integrate cyber into the DevOps pipeline, which the industry has started to call DevSecOps,” said Mark Troester, VP of strategy at Progress, a software company offering tools for developers and IT. “To make design a part of the iterative process of DevOps, teams need to think about including designers during the complete development process, something along the lines of how cyber has become part of the iterative process. In other words, teams should be embracing the concept of DesignOps,” Troester said.

To understand the challenges this creates for those looking to include design as part of the DevOps process, one only needs to look at how design, specifically user experience/customer experience (UX/CX) design, was done in the past. Designers would use tools such as InVision Studio, Axure, Proto.IO, Adobe XD, or one of the many other tools available, to prototype the look and feel of an application, or, more specifically, the end-user experience. The term DesignOps was coined to encapsulate the processes around design. However, DesignOps solely focused on the process of design, such as design workflows, design tools, design governance, team management, budgets and so on.

The ultimate goal of DesignOps was design creation; that design was then passed on to those who would write the code and develop the logic to bring that design to fruition in the form of an application. DesignOps worked rather well when an organization was adhering to waterfall development methodologies, where each step was clearly defined and the goal was to deliver a complete, finalized application to those requesting it.

“Larger organizations were able to field large design teams and could afford to implement a complete design system. When you have 50 or more designers, a complete design system becomes critical to manage design,” said Troester. “However, as AppDev has evolved into a more agile process, especially under DevOps, the disconnect between design and development became a significant problem.”

What Troester is alluding to is the reiterative development cycle used by DevOps teams, where applications are delivered in pieces and then further modified based on user feedback or business operational changes. Businesses today are embracing agile concepts, so they can react much faster to changing market conditions. This, in turn, means modifying applications as quickly as possible to maintain a competitive advantage. Currently, design remains somewhat siloed, and can become a bottleneck for implementing changes if the UX/CX must be modified to address those needed changes.

“With the rise of DevOps, teams need to start thinking of reiterative processes, where DesignOps integrates with the DevOps team, so there is collaboration between the designers and the developers, allowing design changes to happen quickly,” Troester said. “Yet, there are still remaining challenges – some created by the COVID-19 crisis – where designers and developers may not even be in the same building, much less the same time zone,” he said.

To Troester’s point, the COVID-19 crisis has forced businesses to evolve in ways that were once thought impossible. Developers, designers and even operations teams and individuals may no longer be sharing office space, and might be distributed across multiple locations. That complication will drive the need for better collaboration tools that bring design into the DevOps cycle.

“DevOps teams, as well as DesignOps teams, should be looking into technologies that can bridge the designer/developer divide. It will be critical in the near future to facilitate collaboration between design and development,” Troester said. “Perhaps, the answer lies with building some type of bi-directional API into design systems, which can play a key role in the implementation and support of design-first experiences,” he added.

Existing solutions to the current divide seem to be few and far between. But, that does not mean DesignOps and DevOps teams should not be currently looking for a solution to what will become a major problem as DevOps accelerates in the enterprise.

March 11, 2021
LinearB Raises $16M for Software Delivery Intelligence

LinearB announced today it has raised an additional $16 million in funding to advance adoption of a software delivery intelligence platform.

Ori Keren, LinearB CEO, said rather than relying on antiquated processes that require software development teams to track progress by reentering data into a project management application, it’s now possible to automatically collect all the relevant data required from the tools and platforms being employed to build software.

The LinearB platform correlates DevOps pipeline data gathered from code, Git, projects and releases to provide visibility and context to every member of the development team. LinearB employs machine learning algorithms to construct and correlate that data, in real-time, to provide accurate insights into project status. That’s critical, because it empowers every individual on that team to make informed decisions about which tasks to prioritize without waiting for an explicit directive, Keren said.

LinearB will, in part, use the funding to build integrations with a wider range of DevOps platforms and tools, Keren added.

Software delivery intelligence differs from value stream management (VSM) platforms; though they provide similar insights, those surfaced by LinearB are aimed at developers rather than C-level executives trying to optimize deployment of limited resources across multiple teams, said Keren. In many ways, the data collected by LinearB could be employed to better inform a VSM platform, Keren added.

LinearB, in contrast, makes it easier to identify which teams and projects need additional help in near-real-time using metrics surfaced in a dashboard that track, for example, cycle times. The goal is to provide insights that make it easier to predict and eliminate project delays, remediate high-risk code before it is included in a production environment, eliminate bottlenecks and make certain the focus of the DevOps team remains on tasks of the highest priority.

More than 1,500 software development teams are already using LinearB as an alternative to traditional project management applications. Most of those customers are building commercial applications, so the goal now is to extend the reach of LinearB into the enterprise, said Keren.

LinearB, of course, doesn’t eliminate the need for project managers. However, it does eliminate the need for project managers to nag developers to update a project management application. Given the rate at which application development projects are now updated, much of the data in a project management application is outdated shortly after it is entered.

There’s a lot of pressure on application development teams these days. Many projects have been accelerated as part of an effort to more rapidly embrace digital business transformation in the wake of the economic downturn brought on by the COVID-19 pandemic. The challenge for many developers is they, too, are working from home to help combat the spread of the virus. That often results in interactions with managers over video conferencing calls that lack context. Having access to a software development intelligence platform should enable everyone with a vested interest in application deployment speed to make more informed decisions faster.

March 10, 2021
No-Code Tech and the Rise of Citizen Developers

In today’s increasingly remote-first work environment, technical frustration affects all levels of an organization. Because of this, IT leadership teams are looking for new ways to empower and streamline their organizations through the use of innovative technologies. And with remote workforces on the rise, it’s an ideal time to implement new solutions that improve how employees interact and collaborate with each other.

As a result, more organizations are looking to adopt no-code automation in an effort to streamline their workflow processes. By doing so, businesses empower the average employee to become a citizen developer – and with so much room for no-code solutions to grow, it’s safe to say the era of the citizen developer is just beginning.

No-Code Solutions Empower Employees

Behind-the-scenes operations are a major contributor to the success of any business. Time wasted on mundane tasks can limit productivity, which, in turn, can minimize output. For example, in the finance world, traders use code to automate financial data scans so they can find the correct information quickly and maximize their gains – transforming an hour-long task into a simple button click.

The average employee, however, likely lacks the technical ability to create a function like this; and this is where no-code solutions come into play. With the proper no-code solution, any employee can implement solutions to refine and automate their own workflow processes – as well as processes across the entire organization.

There are a few key benefits to doing this. First, an improved workflow means employees will have more time in their day to focus on the strategic, less-tedious tasks. Assignments that require critical thinking will receive the attention they deserve without being backlogged by other work. Another factor is the current state of the global remote workforce. Although this way of working has become the new normal, connecting to a video conference room to brainstorm or to facilitate meetings can still feel fruitless, at times. An improved workflow can enhance how these remote collaborations take place, and will unlock more potential for those involved.

Improved operations can also help to achieve a better work-life balance for employees; freeing time to take more breaks and reducing the potential for burnout that so many have faced over the past year. Not to mention the positive impact more streamlined operations can have on creativity across the workforce, which is a crucial part of driving business success. An employee in the role of citizen developer can unlock a spark of creativity when they realize the power they have and the magnitude of what they can accomplish with no-code solutions.

Let IT Teams Focus on What’s Most Important

Aside from benefits to themselves and the business, citizen developers can have a positive impact on the IT teams within their organizations. In addition to keeping staff technology in working order through longer-form remote interactions, IT professionals must maintain and monitor a remote infrastructure that limits disturbance to company operations and maintain vigilance for security vulnerabilities that have surfaced due to remote work. With all of these factors in mind, the last thing IT teams should be worrying about is an employee’s effectiveness in their role.

No-code solutions empower employees to take the reins on their own workflow processes and gives IT teams more time to focus on critical issues related to infrastructure, security and ultimately, business continuity. When employees use these solutions to their fullest potential, it’s a win-win situation. As a result of the pandemic, we’ve had a glimpse into the future of what the digital business world will look like, and we’re only in the early days of this transformation. The earlier employees are able to gain access to no-code solutions and step into their role as citizen developers, the better organizations will be in the long run.

March 10, 2021
5 Steps to Successful DevOps Culture

The late business management guru Peter Drucker coined the phrase, “Culture eats strategy for breakfast,” and the phrase has endured through the years. Your people must be passionate and enthusiastic about executing business strategy, or it – and your business – is doomed to fail. But remember that company culture itself needs a strategy to complement the business.

DevOps, too, will not succeed without the right culture. As I said in my book “Engineering DevOps,” “Culture is a door to Engineering DevOps,” because if leaders and people do not work in accordance with DevOps principles, then no tool or engineering process will be sufficient to succeed with DevOps. In my (and others’) experience, culture challenges are the No. 1 obstacle that many organizations need to overcome to succeed with DevOps. But changing culture is not easy. Values, beliefs, behaviors and work habits are deeply ingrained in organizations. Organizational inertia and deep-rooted habits are much harder to change than tools or process changes. Transforming organizational culture for success with DevOps requires a strategy, goals and sustained commitment.

In her article, “5 Steps to Change Your Company Culture,” Kate Heinz prescribes five practical steps for cultural change which also are highly applicable to DevOps culture transformation.

Step 1: Determine Core Values

Start by clarifying the values that are most important to accomplishing the long-term strategic goals of the organization. With DevOps, typical strategic core values could be responsiveness to customer needs, speed of innovation, technology leadership and software products and services resiliency, for example. Collaborate with all the key stakeholders including executives, long-term employees, sales teams, key suppliers and HR to obtain alignment on core values before executing the next steps.

Step 2: Set Your Culture Goals

In his article, “7 Key Principles for a Successful DevOps Culture,” Kaya Ismail identified seven principles that can form a framework for determining your DevOps culture goals.

1. Foster a Collaborative Environment – Break down silos to bring people, processes and tools towards a unified focus on the customer.
2. End-to-End Responsibility – All people in the value stream need to be fully accountable for the application and outcomes from beginning to end.
3. Encourage Continuous Improvement – Optimize value streams using integration toolchains and automated processes to realize quick lead times and fast customer feedback to continuously improve performance.
4. Automate Almost Everything – Automated CI/CD processes, infrastructure provisioning, testing, deployment and security compliance require a skilled workforce.
5. Focus on Customer Needs – DevOps teams must continuously pay close attention to ever-changing consumer demands and be ready to respond quickly.
6. Embrace Failure and Learn – A “climate for learning” in which failures are viewed as opportunities to learn makes people feel safe and empowered to transform their work.
7. Unite Teams and Expertise – The scope and complexity of DevOps requires team members to share knowledge and cross-train so they are well-rounded and have a balanced set of skills.

Step 3: Assess Your Existing Culture

Conduct interviews and surveys with employees and key stakeholders to determine where there are deviances from the culture goals set in Step 2. Communicate an analysis of the assessment findings to all stakeholders, pointing out important gaps, areas for improvement and the general plan to close the gaps.

Step 4: Map Out the Plan

Develop a roadmap to address the gaps identified in Step 3. Include specific tasks, timelines, benchmarks and responsibilities. Tasks and items may include targeted workshops, training, selective new hires, organizational changes and, most importantly, rewards and consequences – the real drivers of behavior and culture. One caution about training: as Thane Bellomo explained in his article, “Training Doesn’t Change Culture,” training alone does not have the power to fundamentally change culture.

Step 5: Evaluate Your Progress

Communication, surveys and interviews are important so individuals can provide feedback and track progress. Use the feedback you receive to verify that culture goals are being improved upon, and to reinforce to everyone that the culture changes are important. Use DevOps metrics such as lead time, release frequency and time-to-restore service to demonstrate that the culture changes are helping the organization achieve the strategic values set in Step 1. As you monitor progress, be mindful of pitfalls. As Larry Senn explained, “The Top 4 Reasons Culture Change Initiatives Fail” are: lack of consistent leadership from top management, inadequate personal involvement, disconnected initiatives and lack of top-to-bottom momentum. Be prepared to make corrections based on the evaluations to ensure your culture transformation stays true to your DevOps strategic values and culture goals.

What This All Means

Success with DevOps requires the right kind of culture. Changing culture is no small feat, but it can be done if approached strategically. The five steps described in this article provide a framework for organizational culture change that supports DevOps.

March 10, 2021
Terminal Separation

March 10, 2021
Open Mainframe Project Kicks Off First Quarter with New Members, Additional COBOL and Linux on Z Resources and Launch of the 2nd Annual Open Mainframe Summit
- OMP welcomes ASG Technologies, BMC Software and High School Technical Services to its global ecosystem
- COBOL Check, a new testing framework for COBOL applications, will complement the COBOL Training Course and leverage the support of the COBOL Working Group
- ConsoleZ is a new project that will modernize z/VM and zLinux
SAN FRANCISCO, March 9, 2021 – The Open Mainframe Project (OMP), an open source initiative that enables collaboration across the mainframe community to develop shared tool sets and resources, today welcomes ASG Technologies, BMC Software and High School Technical Services as well as COBOL Check and ConzoleZ to its growing global community.

“Despite the pandemic, Open Mainframe Project experienced record growth over the past year,” said John Mertic, Director of Program Management at the Linux Foundation. “We more than doubled the number of projects hosted and that is a direct result of the commitment and talent of our members and contributors. Their passions are pushing projects to meet technical milestones and members are collaborating on governance, which has helped Open Mainframe solidify our role as the premiere resource for devops technology and education.”

COBOL and Linux on Z Continue to Take Center Stage

COBOL’s ability to support digital transformation is measurably faster and lower-risk than any of the alternatives, which is why there is an estimated 200 billion lines of code being used today. COBOL’s value to the IT industry and global economy is sometimes underestimated, as is its contemporary usage and viability. COBOL is up-to-date technology, supporting the latest advances and innovations such as micro services, containers and cloud.

COBOL Check aims to enable unit testing for COBOL applications, including those hosted on IBM Z systems, and can support micro testing off-platform on Windows, OS X, Linux, or Unix. It has no dependencies on resources hosted on the Z system, which makes it easy to implement and key to supporting future technologies. For developers, COBOL Check will reduce code modifications and offers a shorter lead time to production. The program also improves the design, understandability, maintainability, and longevity of core business applications and supports IBM’s mainframe modernization program by enabling restructuring of existing applications of APIs. COBOL Check will complement the COBOL Training Course and will leverage the support of the COBOL Working Group.

ConsoleZ strives to modernize Linux on Z by offering a new open source tool for z/VM and zLinux. It is a web user interface that gives browser access to z/VM console data and CP commands, while limiting access to certain teams. It can save more time and resources so teams don’t have to interact with many z/VM LPARs. ConsoleZ is secure, efficient and has a better user interface.

Continued Growth of the Ecosystem

Open Mainframe Project, which launched in 2015 by The Linux Foundation, is now comprised of 43 business and academic organizations. Today, the project welcomes ASG Technologies, a leading provider of solutions for the information-powered enterprise; BMC Software, a global leader in software solutions for the Autonomous Digital Enterprise; and High School Technical Services, which offers coding and technology services in 50+ topics for students and adults.

“The world’s largest organizations continue to rely on the mainframe,” said Jeff Boatright, Senior Vice President, Development at ASG Technologies. “As they accelerate digital transformation, advancing the mainframe ecosystem is more critical than ever. We’re thrilled to join Open Mainframe Project and contribute our expertise in enabling organizations to modernize mainframe culture, processes and tools and to empower the next generation of mainframe professionals.”

“We’re excited to bring the combined expertise and experience of BMC, Compuware, and RSM Partners to the Open Mainframe Project to support ongoing innovation on the mainframe,” said John McKenny, SVP and General Manager of ZSolutions at BMC. “With mainframe processing and transaction levels increasing in most industries, there is an increased need for compute power to support mission critical applications, and mainframe modernization is absolutely critical. We have a deep relationship and history of collaboration with the Open Mainframe Project and look forward to working with other members for an open source future of the mainframe.”

“Through our live events and training services, we teach how to build and manage mainframe applications and promote best practices for mainframe design, development and maintenance,” said Matt Zand, Program Manager for High School Technology Services. “As a provider of advanced training to students and adults, HSTS is excited about partnering with Open Mainframe Project and contributing to the education and training projects like Mainframe Open Education, the COBOL Training Course and the Mentorship Program.”

The new members will collaborate on vendor-neutral open source projects with the mission of building community and adoption of open source on the mainframe. The project strives to build an inclusive community through investment in open source projects and programs, career development, and events that provide opportunities for the mainframe community to collaborate and create sustainability.

Open Mainframe invites you to…

Ask Questions! The Linux Foundation is hosting an Open Mainframe Project Open House on March 9 at 1-2 pm PST. Current member companies Broadcom, IBM and Vicom Infinity as well as a professor from East Carolina University and graduate of the Mentorship Program will be online to answer questions and discuss the mainframe community. This session is open to anyone interested in membership in the Open Mainframe Project. Register here.

Apply! The annual Open Mainframe Project Mentorship program, which has helped more than 40 students learn more and gain experience with Linux, open source, and mainframes, is looking for mentees for the Summer Mentorship. Read more here and apply before March 31.

Sponsor! The 2nd Annual Open Mainframe Summit will take place virtually on September 22-23, 2021. Last year, the digital event brought more than 380 registrants from around the world. This year, the Summit promises to be bigger and better with a stellar roster of speakers and more engagement and networking opportunities. To become a sponsor, click here.

For more details about Open Mainframe Project, visit https://www.openmainframeproject.org/.

About the Open Mainframe Project

The Open Mainframe Project is intended to serve as a focal point for deployment and use of Linux and Open Source in a mainframe computing environment. With a vision of Open Source on the Mainframe as the standard for enterprise class systems and applications, the project’s mission is to build community and adoption of Open Source on the mainframe by eliminating barriers to Open Source adoption on the mainframe, demonstrating value of the mainframe on technical and business levels, and strengthening collaboration points and resources for the community to thrive. Learn more about the project at https://www.openmainframeproject.org.

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

###
March 9, 2021
Linux Foundation Project Secures Software Supply Chains

The Linux Foundation today embraced a sigstore project founded by Red Hat, Google and Purdue University to make it simpler for developers to employ cryptographic software, enabled by transparency log technologies, to secure software supply chains.

Luke Hinds, security engineering lead in the office of the CTO at Red Hat, said he and Dan Lorenc, a staff software engineer for Google, led a small team creating a lightweight mechanism for signing software artifacts, such as release files, container images and binaries, in way that creates an immutable, tamper-proof log.

Now, the goal is to take that project to the next level by contributing it to the Linux Foundation, at a time when the focus on software supply chain security has increased in the wake of a spate of high-profile breaches. As part of that effort, a free service, based on sigstore, will also be made available by the Linux Foundation to make the cryptographic software easily accessible to a wide range of developers.

Hinds said one of the reasons that artifacts are not signed by developers is that the current processes employed are too cumbersome. The cryptographic software is designed to be integrated as an extension of existing workflows, Hinds noted.

Because the log created is immutable, everyone participating in the software development process, including auditors, can now transparently track chain of custody for any software artifact, Hinds said. At its core, sigstore creates a set of short-lived ephemeral keys with a trust root based on an auditable public log.

Existing approaches rely on digests stored on insecure systems that are susceptible to tampering. Cybercriminals can, for example, swap out digests if they can gain access to compromised credentials. Those types of targeted attacks can be thwarted using sigstore, because the log management system that underpins it is immutable, said Hinds.

Of course, no system for securing software supply chains is going to be useful if developers won’t employ it. Key management, key compromise/revocation and the distribution of public keys and artifact digests are challenging to manage. Developers, then, need to determine which keys to trust in addition to learning how to sign them when different platforms are employed. Digests and public keys are also often distributed across vulnerable websites susceptible to hacks, or stored as a README file on a public git repository.

As organizations embrace DevSecOps best practices, it’s only a matter of time before the entire software supply chain comes under greater scrutiny. Ultimately, the issue will come down to finding a way to secure those supply chains, either from the top down by deploying and maintaining a platform, or simply making it easier for developers to better secure artifacts from the bottom up.

Regardless of approach, the signing of software artifacts should, one way or another, become more routine in the weeks and months ahead. The biggest challenge will be overcoming the simple inertia that currently exists among developers who routinely ignore the whole process.

March 9, 2021
GitGuardian Reports Careless Handling of Application Secrets

A new report, the 2021 State of Secrets Sprawl on GitHub, published today by GitGuardian, a provider of a tool for monitoring usage of application secrets, suggests developers are not especially good at keeping those secrets safe.

Based on an analysis of every single commit made to GitHub, the report finds there has been a 20% year-over-year increase in the number of secrets – such as application programming interface (API) keys, private keys, certificates, usernames and passwords – discovered on a public repository.

Developers, as they build an application, make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete the secrets they stored in GitHub.

GitGuardian CEO Jeremey Thomas noted that cybercriminals are now actively scanning repositories looking for secrets that would enable them to compromise applications.

As the number of application development projects being launched increased, so too did the number of application secrets being stored in repositories like GitHub. The GitGuardian report notes 60 million repositories were created in the last year, representing a 35% increase over the previous year. GitGuardian claims it detected more than 5,000 application secrets per day. Most of those secrets have been detected in repositories that belong to developers (85%), while the other 15% belonged to organizations. The top four countries where secrets were disclosed were India, Brazil, the United States and Nigeria.

GitGuardian also notes it sent out 937,539 pro bono alerts to 558,086 developers last year that informed developers that application secrets were exposed. The mean time for GitGuardian’s algorithm to detect a leak is four seconds. The average mean time to response of a developer when informed of the issues is about 25 minutes, the report noted.

As a best practice, GitGuardian recommends not storing unencrypted secrets in git repositories, and that unencrypted secrets should never be shared via messaging systems like Slack. DevOps teams should also restrict API access and permissions.

As more attention is paid to how software supply chains are managed in the wake of some recent, high-profile breaches, there is no doubt the number of audits conducted will increase. Many of those auditors will specifically be trying to ascertain how application secrets are being managed. Developers may have to get used to a new, higher level of scrutiny, especially as DevSecOps practices become more widely adopted.

In the meantime, DevOps teams may want to review their dependency on public repositories. There are plenty of private repository options that provide most of the same source code sharing capabilities as a public repository. That may mean someone on the DevOps team is required to manage the private repository, but, given the fact that many regulatory bodies will soon be looking to make an example of organizations that don’t secure application secrets, chances are good those costs will be trivial compared to a fine that would be levied.

March 9, 2021
Kong Integrates Service Mesh with OPA

Kong, Inc. today announced an update to Kong Mesh, built on top of open source Kuma service mesh, that adds support for Open Policy Agent (OPA) software that enables DevOps teams to manage compliance as code.

Kuma and OPA are both being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Kuma, unlike other service mesh offerings, provides connectivity across both microservices-based applications running on Kubernetes platform and monolithic applications deployed on virtual machines.

In addition to adding support for OPA, the 1.2 release of Kong Mesh adds authentication mechanisms between the global and remote control planes operating across multiple zones. That functionality extends the Kuma Discovery Service (KDS) to support multiple authentication mechanisms.

Finally, Kong has added support for the federal information processing standard (FIPS).

Like the Istio service mesh, advanced by Google and IBM for Kubernetes environments, Kuma is based on open source Envoy proxy software. In contrast, however, Kuma is both lighter-weight and designed to span both cloud-native and legacy application environments.

Marco Palladino, CTO at Kong, said OPA support will be a significant advance for both classes of workloads as organizations start to employ Kuma within the context of zero-trust computing environments. As DevSecOps processes are extended to include managing compliance as code, OPA will provide a programmable mechanism for ensuring that policies are not only properly implemented, but can also be easily audited, Palladino said.

In general, an effort led by Kong, VMware and others to elevate the service mesh conversations to more broadly address application connectivity is underway. A service mesh, at its core, provides the means for integrating hundreds of application programming interfaces (APIs) at scale. It also provides a level of abstraction above the network layer that makes it easier to connect applications across a heterogeneous networking environment.

Kong is making a case for a lighter-weight approach that spans multiple platforms and is highly extensible. As such, third-party vendors and IT teams can add extensions to Kuma as they see fit.

Ultimately, Palladino said, the time has come to take cloud computing to the next level. If all organizations wind up doing is lifting and shifting monolithic applications to public clouds, an opportunity to advance the state of IT will have been lost.

Of course, it’s still early days as far as adoption of service meshes are concerned. Most organizations today are relying on API gateways, proxy software or ingress controllers to manage APIs. It’s not clear to what degree a service mesh may remove the need for some of that existing application connectivity middleware.

Regardless of which approach is ultimately favored, it’s apparent that, as microservices-based applications become more widely deployed, a different approach to application connectivity will be required. Monolithic applications, however, are not going away. In some cases, a monolithic application might be carved up into a smaller set of microservices, but it’s unlikely that every existing monolithic application will lend itself to that architecture any time soon.

March 9, 2021