devopsy.kinsta.cloud

Tag: workflows

  • Digital.ai Embraces Multiple AI Classes to Advance DevSecOps

    Digital.ai Embraces Multiple AI Classes to Advance DevSecOps

    Digital.ai has committed to adding generative artificial intelligence (AI) and additional machine learning capabilities to its namesake platform for managing DevSecOps workflows.

    The company plans to make available in alpha a generative AI tool to create test cases and user stories via large language model (LLMs) access via a natural language interface. In addition, generative AI will also be used to identify high-risk changes to code and improve the overall governance of DevSecOps workflows.

    At the same time, Digital.ai has extended the machine learning algorithms it already provides to provide predictions and scoring. Additional capabilities include flow acceleration recommendations, change risk predictions and service management process optimizations.

    Digital.ai CEO Derek Holt said as AI continues to evolve, the company will use a mix of public and private LLM platforms to ingest AI into DevSecOps workflows. In effect, the future of AI will almost be multimodal as different classes of AI technologies are used to automate workflows, he added.

    The goal is to safely break down the silos of data that today make it difficult to cost-effectively build and deploy secure software without compromising the rate at which it is developed, noted Holt.

    It’s still early days as far as the infusion of AI in workflows is concerned, but it’s apparent that many of the manual tasks that prevent organizations from fully embracing best DevSecOps practices will be automated.

    At the same time, increased reliance on digital processes, coupled with more stringent pending regulations, are reducing the overall tolerance organizations have for insecure software. The only way to address that rising sense of application security urgency—at a time when more complex cloud-native applications are being built and deployed—is to rely more on automation. In fact, the race is now on to secure software supply chains before regulations that will have stiff penalties for security lapses go into effect.

    Most of the AI advances in software development that have been made thus far benefit developers. However, many of those same core AI advances will soon be applied to software engineering. Many of the DevSecOps bottlenecks that exist today will start to fade away as various classes of algorithms are able to both identify and make recommendations to eliminate them. As those capabilities evolve, it should also serve to help reduce the long-standing cultural divide between application development teams and cybersecurity professionals that is at the root of the software supply chain issues that organizations are still struggling to resolve.

    In fact, many organizations would be well-advised to review their current workflows with an eye toward determining which processes can be automated. The days when AI was sparingly used are now giving way to a new era of software development that promises to dramatically accelerate the rate at which applications can be built, deployed and updated. The challenge, as always, is finding a way to incorporate these advances into workflows that were not created with AI in mind.

  • Cycloid Adds Templates to Simplify GitOps Workflows

    Cycloid Adds Templates to Simplify GitOps Workflows

    Cycloid today added a Bootstrap Stacks capability that provides DevOps teams with the ability to build Git templates or use ones created by the company to define cloud computing environments.

    The capability is accessed via a portal added to the Cycloid platform for automating software delivery. It also makes it simpler for DevOps teams to reuse templates that are compatible with Terraform or Kubernetes environments as needed.

    In the months ahead, Cycloid plans to release Headers, a metadata tool that automatically populates project parameters in display pages and a project management tool to provide a unified view for each development environment, including continuous integration/continuous delivery (CI/CD) pipelines, documentation, automation, logs, cloud costs and carbon emissions.

    Cycloid founder Benjamin Brial said the templates provide a layer of abstraction that makes it simpler to implement GitOps workflows. As a best practice, GitOps enables DevOps teams to unify the management of code to provision IT infrastructure and software delivery. However, providing access to a Git repository alone is insufficient, said Brial. DevOps teams need access to a set of templates that automate the process and eliminate what is otherwise a complex set of tasks, he noted.

    Easily discovered templates also eliminate organizations’ tendency to create redundant automations simply because a development team was unable to find an existing framework that another team already created, added Brial.

    That approach also enables DevOps teams to more easily embrace platform engineering principles to centralize the management of DevOps using a Bootstrap Service catalog embedded within the Cycloid platform, said Brial. That capability makes it possible to enforce GitOps policies in a way the developers will have to respect because the automation frameworks are readily available, he added.

    It’s not clear whether organizations are embracing platform engineering. Historically, adoption of DevOps workflows in most organizations has tended to flow from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of a corporate standard.

    At the core of any approach is the assumption that centralization will reduce costs by eliminating redundancy. Issues can arise, however, when centralization results in loss of flexibility. Many of the teams that adopt DevOps want to be able to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, it’s just a matter of time before those teams start to look for ways around the corporate standard.

    Each organization will need to strike a balance between flexibility and the need to bring some order to DevOps workflows. In the meantime, however, the pace at which multiple software development initiatives are being launched is likely to force a platform engineering conversation that, in many cases, many organizations have postponed longer than anyone cares to admit.

  • Despite DevOps, Software Supply Chain Security Challenges Persist

    Despite DevOps, Software Supply Chain Security Challenges Persist

    A survey of 397 IT, cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) found that while most respondents work for organizations that have adopted DevOps practices, multiple software supply chain security issues and DevSecOps concerns have yet to be addressed.

    The survey, conducted on behalf of Data Theorem, a provider of a platform for securing application programming interfaces (APIs), the survey also found 82% of respondents have adopted DevOps, with 51% reporting they make extensive use of DevOps workflows (51%). Nearly three-quarters (73%) are deploying code weekly and 31% are deploying code daily.

    However, securing DevOps workflows remains a work in progress, with 41% reporting security teams lack visibility and control of development processes. Other issues include new builds deployed to production with misconfigurations, vulnerabilities and other security issues (40%), developers skipping security processes (39%), software released without going through security checks and/or testing (38%), lack of security process consistency across different development teams (38%), security team can’t keep pace with release cadences (34%) and developers’ reluctance to work with security (29%).

    API security is also becoming especially challenging, with 92% of respondents dealing with at least one API security incident in the last 12 months. Well over half (57%) have dealt with multiple API security issues in the last 12 months.

    On the plus side, the survey also found that more than half (54%) of teams responsible for securing APIs are involved with development as soon as or before the APIs are published. A full 97% said developers either have a good (22%) or high level (71%) of API security knowledge. A total of 89% reported their organization provides formal API security training to their development teams. More than three-quarters (78%) can remediate an API vulnerability within a day, and 39% reported they can do so within hours. A total of 60% reported a dedicated budget has been specifically allocated to API security, with another 30% identifying it as a discrete item within their cybersecurity budget. Two-thirds (66%) said spending on API security would significantly increase in the next 12 to 18 months.

    The use of APIs is only going to increase in the months and years ahead. Well over one-third (36%) of respondents are using APIs across all their applications, with 50% expecting this to be the case in two years. Another 44% reported most of their applications are using APIs., with 32% expecting this to be the case in two years. More than three-quarters (76%) of organizations reported that they have an average of 26 APIs per application and 53% have more than a quarter of their APIs facing the internet.

    More than a third (35%) are updating APIs daily while another 40% do so weekly. A full 61% are using APIs to connect microservices.

    Data Theorem COO Doug Dooley said those APIs are now being targeted by cybercriminals that routinely test the weaknesses of every API after each deployment and update. The most common types of API attacks reported by survey respondents included exposure of data (32%), account takeover (31%), denial of service (DoS) attack (31%), attack on misconfigured API (30%), fake account creation (28%), API injection attack (28%), ransomware (27%), data breach (26%) and content scraping (26%).

    Despite these issues, however, nearly three-quarters (74%) of survey respondents said they believe their organizations have a robust API security program in place, with 22% reporting they have some process in place. Organizations are using a mix of approaches including API security tools (59%), web application firewalls (WAFs) (57%) and API gateways (50%), distributed DoS mitigation (48%) and bot management solutions (42%).

    Challenges included managing multiple tools (29%), visibility into and control of APIs (28%), inventorying APIs (27%), inconsistent adoption of APIs (27%), API security testing (27%), data governance/exposure (26%), discovering and remediating misconfigured APIs (26%), keeping pace with threats (26%) and accurately tracking API usage (25%).

    Significant API security concerns included API authentication issues (41%), account takeovers (39%), identifying and tracking third-party APIs (38%), using tools not purpose-built for security (38%), shadow/undiscovered APIs (38%), abusive behavior bypassing app security tools (38%), denial of service attacks (38%), data governance and/or data exposure issues as a result of insecure APIs (37%), abusive behavior bypassing bot management (37%) and outdated/unneeded APIs, also known as zombie APIs. (33%).

    The type of vulnerabilities that are of the greatest concern are sensitive data exposure (34%), access control vulnerabilities (31%), API business logic flaws (31%) and DDoS attacks (30%).

    More than 79% of respondents, however, are relying on manual testing and review processes to ensure APIs don’t expose sensitive data (79%), with 63% having automated alerting capability for when sensitive data is exposed.

    Overall, it’s apparent that more resources as being applied to securing software supply chains in general and APIs specifically. However, given the amount of software being built and deployed, it may be a while before organizations see the return on those investments.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • CircleCI Report Surfaces DevOps Productivity Gains

    An analysis of more than 14 million workflows from thousands of organizations conducted by CircleCI, a provider of a continuous integration/continuous delivery (CI/CD) platform, revealed the mean-time-to-recovery (MTTR) decreased by about 13% year-over-year.

    Half of CI workflows (50%) recovered from a failed run in 64 minutes or less. That compares to 73 minutes or more in previous years, the report noted.

    In general, the report found 50% of workflows completed in 3.3 minutes or less. However, the average duration was approximately 11 minutes. The median workflow ran 1.54 times per day.

    Success rates, as defined by the number of passing runs divided by the total number of runs, was, on average, 77% for default branches and 67%, on average, for non-default branches.

    Naturally, the level of productivity any given DevOps team can achieve is impacted by everything from the size of the team to the vertical industry they operate in. CircleCI CTO Rob Zuber also noted there are other crucial developer productivity metrics, such as the amount of time developers are focused on writing code, that need to be tracked as well.

    The goal for any DevOps team is to abstract away as much complexity as possible to enable developers to spend more time on writing business logic, said Zuber. Unfortunately, as more responsibility for infrastructure and security has shifted left toward developers, many of them are spending too much time managing application environments instead of writing code, noted Zuber. He noted that the cognitive load being placed on developers today is too high.

    Developing applications is, of course, as much an art as it is a science. Organizations can set aside time for sprints to write code, but it’s difficult to dictate when inspiration might strike a particular developer. There is always going to be a need to let developers, for example, write code at odd hours of the day and night. The more friction they encounter in terms of spinning up application environments, the less likely it becomes a developer will spend time squarely focused on writing code, said Zuber. The “zone” is when most of the best code is developed, he added.

    Naturally, there is no set of metrics that are equally applicable to all DevOps teams, but they should pay attention to metrics as an indicator of whether teams are improving, added Zuber. Most developers and software engineers are not going to want to work in a “software factory” where every minute of the day needs to be accounted for within a project management application. Rather than employing metrics as a stick, they should instead be used as an educational tool—a carrot—that drives steady improvement. In addition, organizations should take care to make sure the collecting of metrics doesn’t impede the pace at which applications are being developed.

    As the saying goes, things measured are usually things done; but there is a fine line to be observed when it comes to any goal that requires a certain level of creativity to achieve.

  • Three is the Magic Number: Planning and Executing a Successful DevOps Project

    Three is the Magic Number: Planning and Executing a Successful DevOps Project

    Diligent preparation, clearly defined workflows and watchful monitoring are key to delivering a high-performing DevOps project. DevOps is one of the hottest buzzwords in programming, but everyone seems to have their own ideas when it comes to structuring and deploying a DevOps team.

    In basic terms, DevOps is the integration of developers and IT operations workers into a single group, with the goal of increasing the speed and quality of software deployment. Its creation was a response to concerns over the segregation of teams, which led to communication breakdowns and a lack of cohesion.

    Since its inception, DevOps has grown in popularity, with 83% of IT decision-makers stating that they have implemented this style of working in some form.

    However, transitioning business focus in this way does not guarantee an immediate change in fortunes–this dynamic represents an IT culture shift, with increased emphasis placed on collaboration and interpersonal skills. For this model to yield returns, engineers should be open to new information, technology and ways of working.

    So, what vital steps must a DevOps team take to ensure the successful delivery of a project?

    Understanding the Needs of the Client

    The preliminary stages can make or break a DevOps project. If the team does not emerge with a vivid idea of what the client wants and how this can be delivered, the venture is doomed to failure.

    It is crucial that both the team and the client are willing to put the time in to understand each other’s goals, ensuring that their visions align for the steps to follow. This can be done through a series of meetings and workshops, where objectives are identified and both establish a good comprehension of how the final product should look.

    If executed correctly, the DevOps team will exit the project’s first phase with a well-defined brief and a crystal-clear understanding of what the client wants to see delivered. When this step is rushed, engineers will be held back by a lack of direction, increasing the chances that the finished product will not reflect the client’s hopes.

    Configuring the Environment

    This next phase is where the developmental process of the app begins, which is usually facilitated using a cloud-based solution. The team begins by preparing the environment’s aesthetic, working out the components it should contain and exploring how they should be configured to maximize efficiency.

    It is during this period that cybersecurity measures are added so that the final version of the app is as close to impenetrable as possible. This shows why a DevOps team needs a diverse range of skill sets: Cybersecurity experts are few and far between, but there should be at least one member of the group whose knowledge can be called upon to ensure protective measures are properly implemented.

    A successful developmental phase is underpinned by clearly structured workflows, with the project mapped out step by step and everyone involved understanding where they fit into the plan and how they can contribute.

    However, a DevOps project is rarely smooth sailing from start to finish–development is often disrupted by missed deadlines, bugs and conflicting duties pulling engineers away from their stations. For this reason, agile and multi-skilled team members, who can ably jump in and assist in various areas, are extremely important for ensuring continuity when workflows are derailed.

    Avoid Failing at the Final Stages of the Project

    Just because the development of a product is complete and the app is live, this does not mean it is time for the DevOps team to rest on their laurels and move on to the next project. It is essential that they continue to monitor the app in its early stages so that any bugs can be identified and immediately fixed.

    Engineers should be in place to see how much the environment is burdened and how it responds depending on the rate and number of new users. Any data obtained is a precious commodity and should be treated as such, with teams ordering and labeling results as soon as they are collected.

    Once the baseline data has been gathered, results can be analyzed to pinpoint which parts of the app may need recalibrating. After making these improvements, the final result should be a product performing at an optimal level while also meeting the client’s specifications.

    Don’t Rush the Project’s Process

    At the conclusion of all three phases, DevOps teams should have absolute confidence that the project is headed in the right direction and that they are fully equipped to execute the next procedural steps.

    A well-designed app is far easier to produce when a team is made up of specialists from an array of fields eager to collaborate and communicate with one another. Assembling the right personnel will aid the smooth transition between the stages of a DevOps project.