devopsy.kinsta.cloud

Category: DevOps Practice

  • Codenotary Previews Secure SBOM Creation Service

    Codenotary Previews Secure SBOM Creation Service

    Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

    Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

    Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

    Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

    In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

    Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

    It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

    On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

  • ClickUp Adds Project Management Templates to Invoke ChatGPT

    ClickUp Adds Project Management Templates to Invoke ChatGPT

    ClickUp is adding templates and collaboration tools to make it easier to access generative artificial intelligence platforms such as ChatGPT from within its project management application.

    Haris Butt, head of product design for ClickUp, said ClickUp AI now includes pre-built department-specific prompts that any product managers, developers or designers can easily access rather than having to develop prompt engineering skills to engage a generative AI platform more effectively.

    The templates, for example, make it simpler to produce summaries of project timelines in addition to the ability to automatically generate a whiteboard that lists tasks that need to be finished to complete a project.

    In the longer term, ClickUp is also moving toward developing its own large language model (LLM) using its own data to provide a generative AI experience specifically optimized for project management, added Butt.

    ClickUp is embedding AI into project management applications as part of an effort to eliminate drudgery, added Butt. One of the primary issues that makes project management challenging is that navigating workflows can be challenging, especially for stakeholders that might not be as well versed in, for example, how a Gantt chart flows.

    It’s still early days as far as generative AI is concerned, but it’s already apparent that a wide range of templates are being developed to make it simpler to invoke these platforms. The need for project managers to become well-versed in all the nuances of prompt engineering techniques to optimize generative AI queries is likely to be limited.

    In fact, the general expectation is that every application will eventually include templates for invoking generative AI capabilities. Less clear is the impact that should have on productivity. In the case of DevOps teams, however, many tedious project management tasks should become increasingly automated.

    Generative AI will, of course, soon be employed across the entire DevOps workflow. Many of the tasks that have historically conspired to make DevOps processes tedious will be automated. In fact, many application developers are already using AI to test and review code. DevOps teams that have historically advocated ruthless approaches to automation are likely to be at the forefront of AI adoption.

    There are, of course, concerns about the accuracy of generative AI platforms such as ChatGPT that have been trained using data that hasn’t always been verified. As a result, it’s possible that some of the results being surfaced by these platforms should be reviewed by humans before being acted on. However, LLMs trained on narrower ranges of validated data will soon become commonplace. As those AI advances are made, the accuracy of generative AI platforms that are optimized for specific use cases will increase.

    In the meantime, DevOps teams should be more concerned about being left behind than about how generative AI impacts their employment prospects. There is no doubt generative AI will transform DevOps workflows along with a wide range of processes. The issue now is determining where DevOps teams can add value—and where machines can’t—in an era where IT environments are becoming more complex with each passing day.

  • Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A new Linux kernel drops and layoffs at Amazon Web Services point to trouble. (more…)

  • Things We Should Acknowledge, Part Three: Remotely Good

    Things We Should Acknowledge, Part Three: Remotely Good

    This installment of my off-and-on “Things We Should Acknowledge” series is going to focus on an area that most DevOps teams are skirting, but increasingly will not be able to: Remote work.

    For background, I have worked remotely for decades; my experience spans Fortune 100s, publishing companies and startups—and that’s just full-time work. I’ve worked for a ton of vendors and publications as a contractor, too.

    I will start by making clear my stance on remote work—a stance I’ve happily talked with people about since long before COVID-19 measures made remote work a regular thing. You either thrive working remotely or you wither. There is a small group in the center that can make it work with some effort, but inevitably that effort becomes routine and those in the middle become part of one of the two groups.

    Because people drift toward one of two camps, we get the currently popular stance on, well, everything, which is polarization. But we shouldn’t. Just like positions and people that should/should not be in meetings to resolve problems or people who should/should not have direct reports, we should consider positions and people that remote work is best for.

    And post-pandemic, the vast majority of DevOps roles can be performed effectively in a remote position. That leaves us with the people question. Mostly. Note: There are organizations and roles that need to be local; those are not a topic of this blog. The 99% of other roles/orgs are.

    This topic gets really ugly, pretty quick. If a significant portion of every organization goes remote, city centers in several metropolises will die. That is not conjecture; you can go look into commercial real estate in any information worker hub. It is in a massive slump (and calling it a ‘slump’ is being nice), with occupancy circling the drain and property values plummeting. That is largely because formerly high-demand real-estate is not needed in the volume it was.

    That should not be the concern of any given corporation. It is the corporation’s responsibility to see to shareholder value, not the real estate market (unless they are invested in real estate, which many large organizations are). But if orgs are keeping any offices downtown, it becomes an issue about safety. In other words, it’s about if the collapse of the market means the offices become less safe for workers, regardless of investment. This is not a decision-making bullet point, but it does inform actions. I have a ton more to say on this topic, but it’s a side bit, so for now, this is enough.

    For people who thrive working remotely—and a lot more people now know that about themselves than knew that five years ago—being forced into the office is a non-starter. I have been offered astounding positions at organizations on both coasts over the years, but the ones that came with the “…and you have to move here” demand—I immediately turned down. More people are doing that; some of them truly great employees.

    So, like it or not, DevOps teams are going to have to consider whether all being in the same building is more important than hiring the most qualified co-workers. That is a team/management/corporate decision and always has been. I consider any “We all do this one thing” stance—from “We’re an X shop” to “We don’t do remote” to be a negative, but I don’t have to make these decisions for an organization.

    It does need to be part of the conversation, though. Because the work environment is unlikely to return to pre-pandemic standards, no matter how much some want it to. The more organizations are willing to work with both remote and on-site employees, the more options those employees—your potential coworkers—have. That changes the dynamic, even in light of recent layoffs, because the new job hunt is not tied to “local” anymore.

  • 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.

  • Sendbird Adds API to Invoke ChatGPT From Mobile Apps

    Sendbird Adds API to Invoke ChatGPT From Mobile Apps

    Sendbird today added an application programming interface (API) to its low-code platform for building mobile applications that enables developers to add bots that communicate with OpenAI’s ChatGPT.

    Shailesh Nalawadi, head of product for Sendbird, said this API makes it possible to add the ability to communicate directly with the generative artificial intelligence (AI) platform from within both new and existing applications in just a few minutes.

    Most developers will add natural language processing (NLP) interfaces to complement the graphical user interfaces that most mobile applications today surface, added Nalawadi. It will be up to each development team to determine how best to employ that capability, but Sendbird envisions, for example, a health care application being able to invoke ChatGPT to answer queries, he noted.

    In the longer term, Sendbird will provide APIs to enable mobile app developers to invoke a wide range of large language models (LLMs). LLMs are increasingly being developed for generative AI platforms and are being optimized for a range of use cases.

    While OpenAI’s generative AI model is being widely used thanks mainly to Microsoft, there are already LLMs that are being created for a narrower range of use cases using much less data. DevOps teams should expect APIs invoking any number of generative AI platforms from within applications to become commonplace in the weeks and months ahead as more end user come to expect to be able to engage these platforms from within almost every application Sendbird’s chatbot API can now be invoked by more 1,300 existing mobile applications alone.

    In general, developers have tended to employ chatbots sparingly because they are often too scripted and inflexible. ChatGPT, conversely, provides a much more open-ended user experience. Organizations can also feed historical conversations or customer relationship management (CRM) data to ChatGPT to drive more personalized and accurate responses, given the veracity of some of the data used to train ChatGPT.

    A recent survey of digital quality testing professionals conducted by Applause, a provider of a platform for accessing a networking of independent testers, found nearly one-third (30%) of respondents are dissatisfied with their current chatbot, IVR and conversational assistant experiences, with wrong answers (29%) and a lack of understanding (24%) as the top two reasons cited. The results indicate there is plenty of opportunity for improvement.

    Nearly three-quarters (74%) said they had a positive experience with the ChatGPT generative artificial intelligence (AI) platform, with more than two-thirds (67%) reporting the platform provided helpful answers to questions. In terms of work-related tasks, most said ChatGPT would either be “very” (43%) or “somewhat” (37%) helpful.

    It’s apparent now that generative AI platforms are about to change the way humans engage with machines. Instead of always creating an abstraction to interface with a machine it’s now feasible for interactions to occur between them using language humans readily understand. As such, the way applications are built and employed is about to fundamentally change in ways that are difficult to predict.

  • Platform Reality Has a Surprising Amount of Detail

    Platform Reality Has a Surprising Amount of Detail

    Developer platforms and the platform teams that create them have been the center of attention for quite some time now. There have been many (wildly different) opinions about the subject, ranging from how bad the notion of a platform team is to how essential platforms are to make an organization’s DevOps journey to cloud native successful.

    Since early this year, the CNCF TAG App Delivery team has been working on a whitepaper about platforms. It explains what platforms are, why they are needed and how platform teams might work to create them. Furthermore, there’s an abundance of end-user talks at conferences that show how platform teams and their platforms were essential in enabling developers at scale. Even on the KubeCon + CloudNativeCon keynote stage, we’ve seen success stories of platform teams like the one at Mercedes Benz.

    Developer Platforms Should Enable Developers

    There is no silver bullet to successful platform teams and platforms. However, it is important to understand that the main goal of a developer platform is to enable developers. It is essential for platform teams to focus on delivering that value, which is why we are seeing a trend to introduce actual product ownership and product management roles to platform teams.

    The CNCF whitepaper stated that the three core jobs of a platform team as follows:

    1. Research platform user requirements and plan a feature roadmap.
    2. Market, evangelize and advocate for the platform’s proposed values.
    3. Manage and develop interfaces for using and observing capabilities and services including portals, APIs, documentation and templates and CLI tools.

    I couldn’t agree more. But the reality of day-to-day business for many platform teams means they rarely get to focus on those three jobs.

    Reality Has Detail

    The situation reminded me of a blog post I read a few years ago, titled “Reality has a surprising amount of detail.” The author explained how it is easy for people to get stuck even when faced with a task that might look simple from the outside. They explain how a task as simple as building wooden stairs can, in its many subtasks, become quite complex. Furthermore, when faced with reality, even the tasks that seemed plannable get more complex and need real-life adjustments.

    Most engineers have had analog experiences in their day-to-day work. We can translate this notion into platform engineering quite well. Building a developer platform sounds straightforward at the onset. However, once we get into it, it becomes a rabbit hole of figuring out the CNCF landscape, adding company-specific glue, compliance, security, fixing bugs, getting deep into the open source projects and sometimes, faced with the reality of open source, even becoming contributors and maintainers of such projects.

    Now, I’m not saying that it’s all bad. All these things can be great and rewarding in their own way. Especially with a community like the CNCF, participating and contributing to open source can be a very rewarding experience. You’ll make lots of friends, learn DevOps and development skills and might even further your career significantly.

    While it’s a lot of work, there is a risk that every platform team basically reinvents the wheel. This is because an organization’s requirements seem too large to rely on a single product (or even a suite of products). We end up with bespoke platforms that need a lot of attention. These platforms also have platform teams that don’t have enough time to focus on the higher-level jobs that they were tasked with.

    Platform Evolution

    Over the years talking to and working with platform teams we have built a model of prototypical platform evolution and its risks at each stage.

    Usually, a platform team starts with the task of building a developer platform to enable the product teams to build great software and deliver value to the end users.

    As they build the platform from the first Kubernetes clusters to observability tooling to security, the backlog for features constantly grows. Even with a growing platform team and sub-teams for certain technology areas, there’s a risk that some of these backlog items never get attention. Especially, delayable, non-critical, daunting tasks (like upgrading to the next Kubernetes release) often fall victim to this problem.

    Next, when it comes to operations, the platform team needs to limit the possibilities and breadth of what they offer. Operations responsibility for functionality that is outside of those limits, (for example, a specialized data store) goes back to the product teams themselves, which results in developer distraction.

    Even with a wide coverage of the platform, Day 2 and operations, the next big task for the platform team is advocating for adoption. This is not just marketing for their platform, but also means the platform team has to build user-friendly interfaces and documentation. The risks and alternatives we often see here are that product teams build their own mini-platforms and systems that result in shadow IT. Another common risk is ending up with several competing platforms within big enterprises that are hard to integrate and centralize, which in turn leads to inefficiencies.

    Once we get over the adoption hurdles, it is the platform team’s job to deliver value and high-level capabilities to the product teams’ developers. However, at this stage, often the platform teams have grown and might encompass several sub-teams for technology areas. Additionally, some areas like security might already be under central IT control. The risk we see here is that the capabilities offered are reduced to technology silos. They might cover all areas like observability, connectivity, security and release engineering, but to achieve real maturity, a platform team needs to offer capabilities that span several of those areas.

    Many of the advanced capabilities that we see with more mature end users cover several or all technology areas. Think about a simple high-level capability, like progressive rollouts. It starts with release engineering capabilities to build and deploy the software. From there, we need connectivity capabilities to dynamically route traffic to the new service. Then we need observability capabilities to observe our new version and from there have automated feedback loops to roll back or go forward with the rollout to production. And if that wasn’t enough, as we’re a security-aware organization, we want the whole software supply chain that facilitates this to be secure and trusted.

    Question for the curious cloud native enthusiasts: How many tools do you need to integrate to achieve the above “simple” high-level capability in an automated way? And this is only one of many capabilities.

    PaaS-Like Platforms Without the Downsides

    So, while platforms and platform teams are definitely the way to go, we need to be aware of the amount of work and effort required.

    We need to be aware of the risks and strive towards building highly integrated platforms that deliver high-level capabilities to the product teams.

    However, cloud-native developer platforms, while having similar goals to the PaaS systems of the past, should not follow the same approach of full abstraction. If we just abstract away into bespoke systems that hide everything from the user, we go back to the world of PaaS where at some point the end-user developers hit limits and build workarounds around the platforms.

    Additionally, if we build these bespoke internal platforms, we’ll be stuck with them and need to maintain and evolve everything by ourselves.

    Or, to go back to the blog post I referenced earlier, “At every step and every level there’s an abundance of detail with material consequences.” And we have to remember what we care about. The way to avoid both of these downsides is to bet on open source and stand on the shoulder of giants.

    By building our platforms on open source and using as many of the established or soon-to–be-established standards of our community we can avoid our platforms becoming bespoke. Recent developments like Cluster API, Gateway API and sigstore are some good examples.

    Furthermore, we need to make our abstractions poke-able. While our platforms should come out of the box with user-friendly interfaces and sensible production defaults that enable new product teams to onboard quickly and get their jobs done without having to bother with deep understandings of the underlying technology, we need to keep them open to mature users that know their way around and want to tweak it to their needs. We achieve this by giving mature users the option to access said open standards and APIs safely.

    This is the strength that we gain from a community like the CNCF, so we should use it to build great platform products that stay true to the core of open source and strive to make our product teams as happy and successful as possible. And remember to be happy with ourselves as successful and appreciated platform teams.

  • DORA Report 2022: The Magnitude of Software Supply Chain Security  

    DORA Report 2022: The Magnitude of Software Supply Chain Security  

    The term ‘software supply chain security’ (SSC) can be interpreted in many ways. Following the White House executive order in May 2021 and the European Cyber Resilience Act (CRA) of 2022, both governments and corporations are taking a more active role in ensuring their software is secure. Fundamentals such as having a software bill of materials (SBOM) and being able to cross-reference it with known common vulnerabilities and exposures (CVEs) are now the standard, but supply chain security covers far more than just the software that builds your products.

    To create certainty and clarity, leading standardization bodies such as OWASP, OpenSSF and others have set up ongoing efforts to define and mitigate SSC threats. They have active working groups, SIGs and TACs all working in vendor-neutral ways to help define and solve parts of the SSC problem.

    A great example of this is the continuous work being done by Google Cloud’s DevOps Research and Assessment (DORA) initiative. More specifically, the subject was reflected in the September 2022 DORA report that focused on security in general and supply chain security in particular. Using the Supply-chain Levels for Secure Artifacts (SLSA) framework as well as the NIST’s Secure Software Development Framework (SSDF) as benchmarks for actively addressing supply chain security issues, the researchers assessed how organizations were successful in approaching and addressing threats at all levels of the organization.

    My view of the major findings of the DORA report are summarized below.

    Who Owns Software Supply Chain Security?

    The report stated that organizations should empower individual teams and developers to “own” security while administering a consistent security policy and posture across its products. While I agree with this, we need to examine both sides of the ‘ownership’ coin. By nature, this hybrid approach creates complexity—and even friction—between the security team that, by definition, is responsible for all facets of security and the developers that are being tasked to ‘fix’ security issues in addition to their daily tasks. There has to be common ground between developers, their tasks associated with security and the security team.

    Individuals in organizations that build software care about what they build; they have a stake in the overall success of the final product and this feeling of ownership strengthens that level of care. However, asking for such ownership while adding a security component to the mix without providing sufficient knowledge, tools, proofs, and “power” to make decisions could lead to  a lack of trust, confusion, execution problems and frustration. To alleviate this, the security team should provide developers the tools, education and resources they need to feel empowered to enhance security efforts at the source. Organizations that provide evidence in a scalable, digestible manner are successful in building trust and creating common ground between the developer, security and the security team.

    There’s also another dimension that could potentially create silos between developers and security teams rather than bringing the two together: There’s no one single security team or owner of SSC. SSC is tricky to define as a category; it involves shift left security, runtime security and everything in between. Some portions of it are being governed by the security office, some by AppSec, some by DevOps and some by the developer. The ownership of each isn’t well-defined and the entire effort is very difficult to consolidate as one process or methodology. In addition to upskilling the developer with tools and training, long-term education, thought leadership and access to good technology are the keys to gradually reduce these friction points..

    Security Processes Slow Down Development

    Defining the tools, methodologies and processes that should be employed in an organization to add sufficient security while not impacting development speed is not a trivial task.

    ­­The following are four principals I think correspond well with the SLSA framework and that help address the development slowdown challenge:

    Set preventive measures: Avoid using known vulnerable and malicious packages from the beginning of development. By eliminating vulnerabilities introduced in first-party code (due to bad coding practices) as well as misconfigurations, wrong encryption and secrets exposures, you are preventing known threats from entering your product.

    Examine proactively and continuously: The security state of software changes because the software itself always evolves and new vulnerabilities are continuously being introduced. It makes a software artifact that was just secured suddenly become susceptible to attack. This requires continuously rescanning and revisiting software artifacts as well as frequently recalculating any potential risk.

    Set preemptive measures: Create a plan that initiates a prompt response when a potential risk is discovered. Both development and security teams should create the plan for decision making and execution. The measures should include ways to identify vulnerable artifacts across development and production, how to understand exploitability and true impact and how to prioritize and remediate accordingly.

    Do it all in an automated manner: Create automated processes based on reliable data and scanning tools to dramatically reduce the effort needed by developers and DevOps teams.

    DORA report co-author Eric Maxwell said one of the main principles is to remain tool- and platform-agnostic while focusing on capabilities and practices. From that perspective, automation is essential and it is enabled by security-as-code. Having a common language–code–allows teams to communicate about security as well as collaborate. It drives the things we discussed earlier around democratizing the security process and helps break down silos.

    The DORA findings—alongside the topics described above—encourage community awareness and continued shared efforts to bring much-needed attention to software supply chain security. Gradually, SSC security will evolve, but as it does so, the only way to properly address it is by ensuring the developers and security teams are on the same page and both have ownership of responding to and resolving issues as they appear. For more in depth review of the DORA report I encourage you to view Leap Left for Security: The DORA Report Roundtable.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Monster.com

    Wells Fargo
    Fremont, California
    Lead Software Engineer
    $183,310 to $237,100

    Indeed.com

    Recro
    Aurora, Colorado
    DevOps Engineer
    $150,000 to $200,000

    LinkedIn

    PayPal
    Remote
    Senior Director Enterprise DevOps
    $144,800 to $319,000

    SimplyHired

    Monarch Landscape Companies
    Los Angeles, California
    Director of IT/DevOps
    $140,000 to $150,000

    Dice.com

    Synechron
    Weehawken, New Jersey
    Azure DevOps Engineer
    $100,000 to $120,000

  • GitLab Survey Reveals DevSecOps Gains

    GitLab Survey Reveals DevSecOps Gains

    A global survey of 5,010 IT leaders, CISOs and developers published by GitLab this week found well over half (56%) of respondents are working for organizations that are using DevOps or DevSecOps practices. However, 72% of respondents said they are using a DevSecOps platform (36%) or are considering adopting one in the next year (36%).

    Overall, less than a third of survey respondents (30%) said they were “completely” responsible for application security, with 53% reporting they are part of a larger application security team. Well over a third (38%) of the 1,453 security professionals surveyed said they are part of a cross-functional team focused on security.

    License compliance checks and security capabilities for cloud-native or serverless tied for the top of the list of current priorities (19%), but shifting security left (29%) was the top focus for the coming year. Nearly three-quarters (74%) of security professionals said their organizations either shifted left or plan to in the next three years. Nearly as many (71%) said a quarter or more of all security vulnerabilities were discovered by developers.

    Top frustrations identified specifically by security professionals included testing happening too late in the development cycle (43%) and difficulty prioritizing vulnerability remediation (41%).

    Those frustrations might increase in the coming year, with 85% of security professionals reporting they either have the same or lower budget in 2023.

    On the plus side, nearly two-thirds of the 1,954 developers surveyed said they are either using artificial intelligence (AI) and machine learning (ML) algorithms in testing today or will be in the next three years. A full 62% said they used AI/ML to check code, while 53% use bots for testing and 36% use AI/ML for code review.

    Nevertheless, more than two-thirds of security professionals (67%) said they are concerned about the impact of AI/ML capabilities on their job, with 28% of them admitting they are “very” or “extremely” concerned. Of those respondents who expressed concern, 25% said they are worried about the potential for AI/ML to introduce errors that will make their job more difficult.

    David DeSanto, chief product officer at GitLab, said GitLab is also working to address those concerns by embedding a range of AI/ML capabilities into its platform to optimize DevSecOps workflows and, most recently, enhanced its GitLab Remote Development module to make it easier to centralize the maintenance and security of development environments.

    GitLab this week also announced it is partnering with Oracle to make it easier to use the GitLab continuous integration/continuous delivery (CI/CD) platform to run AI and ML workloads on the Oracle cloud platforms. AI/ML is going to play a critical role in enabling organizations to build and deploy secure code without slowing down the pace of application development, said DeSanto. In fact, many organizations will soon be consolidating toolchains to enable them to achieve that goal, he added.

    The GitLab survey found 57% of security respondents said they use six or more tools, but many of those tools are legacy software composition analysis (SCA) tools that will be replaced as more responsibility for application security shifts left toward developers, noted DeSanto. Two-thirds of survey respondents (66%) reported they want to consolidate their toolchains this year.

    Collectively, the GitLab survey makes it clear that DevOps and DevSecOps practices and platforms continue to evolve rapidly. The challenge, as always, is keeping up with the pace of that change.