Category: CloudBees

  • DevOps World 2022: DevOps is Not Just CI/CD

    DevOps World 2022: DevOps is Not Just CI/CD

    There was a time when pundits said that DevOps was the symptom and CI/CD the cure. While that may or may not be true, there is no denying that CI/CD is the very heart of DevOps. While that might still be true, DevOps today is so much more than CI/CD; it has evolved, far beyond just its core of CI/CD.

    In my preparations for the upcoming DevOps World 2022, held in Orlando, Florida, September 27 to 29, I’ve been briefed on upcoming product announcements by the CloudBees product team. I find it fascinating to see where the CloudBees product line is going. In many ways, CloudBees product evolution mirrors the evolution of DevOps itself.

    Today, DevOps includes areas such as observability, security and compliance, GitOps, cloud-native and more. Developing, integrating, testing and deploying software is only one aspect of today’s DevOps. Without divulging any specific product announcements that CloudBees will be making at DevOps World, I can tell you that CloudBees is on a journey that closely mirrors that of DevOps itself.

    In my opinion, this is as it should be. CloudBees was one of the pioneers of the DevOps movement. By harnessing Jenkins—the original DevOps killer app—CloudBees helped move DevOps into the mainstream. Of course, Kohsuke Kawaguchi (KK), the creator of Jenkins, has moved on from CloudBees and the Jenkins community was always independent of CloudBees. Nevertheless, many of us in the field see CloudBees and Jenkins as inextricably linked.

    While Jenkins is still widely deployed and used, it is no longer the epicenter of the DevOps universe. Over the last couple years, CloudBees has transitioned to become much more than just Jenkins or Enterprise Jenkins and remains at the center of DevOps innovation.

    This year‘s DevOps world will be a great opportunity for CloudBees to showcase just how far they’ve come from being solely the enterprise Jenkins company while remaining a preeminent end-to-end DevOps tools provider. If you want to know just how far, well, stay tuned for our coverage of DevOps World where we will be covering all of the product announcements as well as speaking to CloudBees executives and customers about the new products and product lines and capabilities that will be announced.

    I have written before that the theme for DevOps World this year is DevOps Remix. Our own DevOps Experience virtual event, coming in November, has a theme of DevOps Everywhere. I think both of these themes speak to the same general idea: DevOps is going where it’s never gone before. It has evolved beyond CI/CD to a new way of developing, delivering and managing software that includes securing it and testing it. Over the next few years, I think we’ll see we’re entering a new golden age of DevOps.

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!

     

  • DevOps World 2022: DevOps Tail Wags the Dog of Digital Business

    DevOps World 2022: DevOps Tail Wags the Dog of Digital Business

    As a methodology for building and deploying applications faster, DevOps has been around for more than a decade. But it’s only now that the methodologies and concepts pioneered years ago are starting to wag the dog of digital business transformation.

    Since the onset of the COVID-19 pandemic, digital business transformation has been all the rage. Organizations of all sizes now have a much deeper appreciation for digital processes that enable them to respond more adroitly to changing business conditions regardless of whether the global economy is expanding or contracting.

    DevOps Wags the Dog

    Not too long ago, ironically, business executives routinely complained that IT simply wasn’t fast enough to keep pace with the needs of the organization. At the CloudBees DevOps World 2022 conference in Orlando next month, it will be made crystal clear that businesses are now adopting concepts originally defined by DevOps pioneers to not only keep pace with the current rate of application development innovation but in many ways actually manage the business itself.

    As Mitch Ashley, principal analyst for Techstrong Research, an arm of Techstrong Group, publisher of both devopsy.kinsta.cloud and Digital CxO, recently noted during a podcast, “It’s all about the software.”

    Of course, the shift in the relationship between IT and the business it supports has been a long time coming. The debate over how to close the divide between IT and the rest of business has been going on for decades. Even with the rise of DevOps, it’s been more than 11 years since the Jenkins continuous integration/continuous delivery (CI/CD) platform was officially launched. Today, advances in IT are now happening at a rate that many businesses are struggling to absorb.

    In fact, what started out as small teams of application development and deployment specialists looking for ways to automate the building and deploying of applications has now evolved into a multi-billion dollar sector of the software industry. And it is driving a level of business transformation that hasn’t been seen since PCs running word processing and spreadsheet applications arrived in the 1980s.

    Software is (Still) Eating the World

    Just how big an impact DevOps is going to have going forward is still to be seen. It’s still early days as far as pervasive adoption of DevOps best practices is concerned but, as Marc Andreessen once noted, software continues to eat the world. Today, the bulk of that software is being constructed with DevOps best practices in mind and using everything from containers to serverless computing frameworks that make it simpler than ever to add new capabilities to applications both inside and outside of the cloud. The pace at which technological innovations are being made is only going to accelerate.

    As such, it’s arguably never been more important for DevOps professionals to gather in person to share knowledge and insights. During the COVID-19 pandemic, DevOps platforms evolved tremendously. The teams that use those platforms exercise more influence than ever within their organizations. The best way to appreciate the value of DevOps has always been to learn firsthand how practitioners are employing those principles to achieve a wide range of strategic business goals.

    No matter how large or small the organization, the need to embrace and then continuously improve DevOps processes and workflows is, as always, a pressing concern. Achieving that goal in isolation may be possible, but there’s no doubt in anyone’s mind there’s nothing quite like spending a few days with a few thousand like-minded souls to make attaining those goals a whole lot easier.


    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

  • DevOps World 2022: Developer and Security Links Protect Your Supply Chain

    DevOps World 2022: Developer and Security Links Protect Your Supply Chain

    Ever since the SolarWinds attack back in December 2020, software supply chain attacks have been top-of-mind for any company that builds software. The idea of endangering not just your organization by being attacked but also your customers really sharpens your focus.

    Another complicating factor is that applications use a combination of open software components and homegrown code to deliver applications. This software supply chain means your software can be compromised through no fault of your own but instead based on the components you use. The Log4j attack is an example of a component creating vulnerabilities in any software that uses it. So how do we defend our software? We need to think differently about where security starts and how security concepts can be integrated into software earlier in the development process where it interfaces with the rest of the technology infrastructure.

    Building a Secure Pipeline

    Modern software development is built on the CI/CD pipeline. It allows the application security testing and software composition analysis to happen way earlier in the integration process (shift left), and that allows you to identify and fix issues before the code gets anywhere near customers. Sounds simple, no? Just run your code through a pipeline, integrate security testing, identify issues, fix them, and deploy secure software.

    As with most things, what sounds simple in theory can be challenging to implement in reality. First, shifting left requires a collaboration between developers and security teams. Finding the security issues don’t matter if they don’t get fixed. To increase the likelihood of these issues getting fixed, the security team needs to provide context to the developers regarding the urgency of the flaw or vulnerability and some guidance on the best way to fix the issue. To be successful, security folks can’t just drop a report with hundreds of defects and vulnerabilities on the developers and expect that anything productive is going to happen. If this scenario reminds you of getting a report from your vulnerability scanner with hundreds of issues you won’t fix, well, that’s because it’s very similar.

    Second, security must add value to the development and architecture process by offering up infrastructure-as-code (IaC) templates and a toolchain that makes it easy to implement secure application stacks. Maybe that looks like a template library managed by a cloud security Center of Excellence, which can provide these tools across all of the application teams leveraging efforts.

    Combatting Supply Chain Attacks

    Finally, you can implement a security champions program, training a developer (or two) on each team about security issues and they can act as a security emissary to the developers. This provides scale, ensuring that the security team doesn’t become a bottleneck to fixing the security issues.

    Given the sophistication of the software, the attack surface of the code, and the velocity of the development process, combatting supply chain attacks requires tight and ongoing collaboration with the development team and shifting left to catch the security issues earlier in the integration process.


    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

  • DevOps World 2022: Using SBOMs to Secure the Software Supply Chain

    DevOps World 2022: Using SBOMs to Secure the Software Supply Chain

    As supply chain attacks become increasingly prevalent, visibility is emerging as a necessity in cybersecurity. One way to improve visibility and secure your software supply chain is with a software bill of materials (SBOM). 

    An SBOM is a list of all the components within a codebase. By providing insight into open source and third-party components, SBOMs improve overall visibility and are integral to the identification of security or license threats. To properly secure the software supply chain, organizations must have an understanding of all the components in their applications; it is especially important to do so with containerized applications and those built using cloud-native, microservices-based architectures. That’s why SBOMs are becoming a cornerstone of a comprehensive application security strategy. 

    The Need for Visibility

    Gartner’s recent report Innovation Insight for SBOMs emphasizes the need for constant visibility into the software development life cycle and how SBOMs can help organizations and developers achieve that goal. While Gartner recognizes that open source software is a foundational component of modern software development, it also noted that it can be a major contributing factor in software vulnerabilities. 

    “While reusable components and open source software have simplified software development, this simplicity has exposed a critical visibility gap: Organizations are unable to accurately record and summarize the massive volume of software they produce, consume and operate,” the report said. “Without this visibility, software supply chains are vulnerable to the security and licensing compliance risks associated with software components.” 

    To mitigate the associated risks, Gartner’s report not only emphasizes the importance of SBOMs but the need to automate the SBOM creation and validation process. To achieve supply chain security at scale, organizations should automatically generate and verify SBOMs and use that data to constantly evaluate oncoming risks. 

    This ties directly into the continuous integration and continuous deployment (CI/CD) process, which uses SBOM data and assessments to ensure threats don’t slip under the radar and wreak havoc. You can more easily identify security vulnerabilities at any stage in the pipeline and remove them—because an SBOM gives you more granular visibility.

    The importance of SBOMs has even been noted by the U.S. federal government. As stated in president Biden’s Cybersecurity Executive Order 14028, any company that sells software to the federal government will be mandated to provide a complete SBOM. 

    The initiative has also spread to other branches of the government, with the Cybersecurity and Infrastructure Security Agency also emphasizing the significance of SBOMs. 

    “CISA will advance the SBOM work by facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases,” said CISA in a statement on its website.

    SBOM Requirements

    The U.S. Department of Commerce and the National Telecommunications and Information Administration (NTIA) have outlined the minimum elements required. For one, data fields with baseline information about each component are required. Also, automation support is needed, as SBOMs necessitate machine readability for support at scale. Finally, the need for practices and processes was outlined, calling for frequent SBOM generation, including transitive dependencies and widespread availability of this information to those who need it. 

    On many fronts, SBOMs have become non-negotiable throughout the software industry. In order to effectively detect and respond to threats, organizations must take preemptive steps to ensure visibility is maximized, and SBOMs accomplish just that.


    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

  • Infographic: 8 Trends Shaping Software Delivery in 2022

    Infographic: 8 Trends Shaping Software Delivery in 2022

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/09/INFOGRAPHIC-8-trends-shaping-the-future-of-software-delivery-in-2022-Final.pdf” title=”INFOGRAPHIC – 8 trends shaping the future of software delivery in 2022 – Final”]

  • DevOps World 2022: Why DevOps Needs a Remix

    DevOps World 2022: Why DevOps Needs a Remix

    I was checking out the DevOps World website today to gather information, as Techstrong.TV will be live streaming from the show in Orlando, Florida September 28 and 29, 2022. The theme for this year’s DevOps World is “DevOps Remix.” The more I thought about it, the more it became clear that DevOps Remix is a perfect theme for DevOps World—and for DevOps as a practice.

    What does a DevOps remix mean? Well, I won’t pretend to speak for CloudBees, the event’s host, but here’s what they have on the DevOps World website:

    “The tempo will be faster, more energized, and more harmonious in keeping with the accelerated pace of the DevOps transformation. Progressive delivery, value stream management, and everything from AIOps to XOps are now part of the mix creating new paths, new beats, and faster code releases.”

    That’s what a DevOps remix means to them; here’s what DevOps remix means to me.

    I believe a DevOps remix speaks to the continuing maturation of DevOps as a methodology and a practice and to the DevOps market and community. DevOps is no longer nebulous; there’s no longer a question of “Is it real or not? What exactly is DevOps?” kind of thing. No, DevOps is very much a player in the software development life cycle (SDLC). So much so that as digital transformation continues to involve software in places it hasn’t been before, DevOps is helping it get there. DevOps is going places it has never been before.

    Techstrong Group’s own DevOps Experience event, now in its fifth year and coming this November, has a similar theme: DevOps Everywhere. DevOps, as part of the CI/CD pipeline, still exists, but DevOps today is so much more. To be successful today, organizations large and small (but especially enterprises) need to take DevOps fundamentals and implement them whenever and wherever they are building, deploying and managing software.

    Another reason the idea of a remix is so appropriate is that, as the world emerges from COVID-19 lockdowns, there is something comforting about revisiting in-person events, conferences and training—the ‘normal’ industry activities and events that happened before the pandemic. For those of us in the DevOps space, DevOps World is one of those things. I have been going to DevOps World since before it was even called DevOps World—when it was Jenkins World. There’s a remix for you!  

    DevOps does need a remix, and it’s happening right now. While I do think it’s great to be able to resume many of the same activities, go to the conferences and get training, I don’t expect this year’s DevOps World to be like previous editions in San Francisco or online. That’s part of what makes it such a terrific event—a mix of the old, the new, the tried and true, the cutting edge and the familiar. So, if you consider yourself a member of the DevOps community and can make it to Orlando at the end of September, you should consider being part of the DevOps Remix.

    This year, DevOps World will be held in Orlando, Florida, at the World Marriott Center. The CloudBees folks have published a discount code, DW22, to use when registering that should save you some money on a full ticket for the show, including some training, some great sessions and interactive activities. We can’t wait to see you there for the DevOps Remix!

  • The Power of Automation and Distributed Sources of Truth

    The Power of Automation and Distributed Sources of Truth

    Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much data–including most network configurations–is still updated manually, often in the middle of the night. To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

    Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

    The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

    The Source of Truth

    More enterprises are embracing network automation because they recognize the efficiencies it can deliver when managing complex networks and the benefits those efficiencies can add to the bottom line. But if you’re going to automate your infrastructure, your automation solution will need to gather authoritative information about it from somewhere. This source of truth holds the knowledge needed to enable automation to make changes to the network.

    Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution. But such a solution doesn’t currently exist. Given the multifarious nature of today’s networks, relying on a single source is both impractical and potentially expensive.

    Rather than asking “What is the single source of truth?” perhaps the better question is “What will provide better data: Creating a single source of truth that tries to synchronize to the entire network? Or accessing distributed sources of truth needed to accomplish the automation in real-time?”

    Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to conduct proper and meaningful automation.

    Cast a Wider Net

    If you’re running a service provider network, for instance, your business is your network. If you’ve spent millions, or even a billion dollars on your network assets, it’s worth your time to have a system in place that accurately manages and maintains those assets. A single source of truth won’t provide that.

    Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

    Finally, the process of trying to create a single source also doesn’t address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

    The case for accessing multiple sources of truth is a relatively simple one: it allows for greater flexibility and enables enterprises to more easily leverage data to benefit their business.

    With the advent of programmable networks–machines talking to machines–the most current automation solutions can access multiple distributed sources of truth–different APIs and databases that are responsible for being the source of truth for different parts of the network – and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

    Automation Hesitation

    So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, there’s concern that not having a single source of truth for network data – or data that may not be 100% accurate – will compromise the automation process. It’s a classic “fear, uncertainty and doubt” thought process: “What if the data is only 70% accurate? If we try to automate with bad data, we’re going to break the network 30%  of the time.”

    Some network teams may believe they can’t automate anything until they can combine their five or six sources of truth into one huge database. At the same time, leadership may be pushing those network teams to move forward with automation to get more value from the network. By choosing to wait until they finally have a “pristine” database, they could lose months or even years of time, to the benefit of no one.

    The solution is to take an incremental approach. Look at all the various network assets–programmable, cloud, legacy, etc.–and start the automation process in the areas where good data exists and where a source of truth doesn’t need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

    Being able to utilize multiple sources of truth is better than worrying about having a “perfect” source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

    Just as important as committing to an automation solution that can integrate with multiple sources of truth to make decisions, is deploying the right automation solution. The most effective automation solution will embrace:

    ● API-first–The only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other.
    ● Data federation and transformation–Having unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language.
    ● Unified view–An abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

    Multiple Sources Equal More Actionable Data

    With today’s modern, programmable networks–and the absolute necessity for enterprises to have access to accurate, real-time network data–relying on a single source of truth is based on a flawed assumption that we can always have a synchronized database, and therefore is not a viable strategy.

    By adopting network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth, mitigating data quality issues and manual errors.

    As an enterprise implements its automation strategy, having multiple sources of truth within the network will result in more accurate, timely and actionable data for automation to succeed, which will increase efficiency and drive the business forward.

  • The 6 Pillars of DevSecOps: Pillar One-Collective Responsibility

    The 6 Pillars of DevSecOps: Pillar One-Collective Responsibility

    With the increased interest in DevSecOps, the Cloud Security Alliance (CSA) and Software Assurance Forum for Excellence in Code (SAFECode) brought together a DevSecOps Working Group to identify and share best practices for the development and maintenance of a DevSecOps program. This working group identified and defined six focus areas critical to integrating DevSecOps into an organization; this article will focus on pillar one⁠—collective responsibility

    The Context of Security

    When we look at security historically, we find that it has often been relegated as a secondary objective when compared to other primary objectives like releasing features to market quickly. The rationale is that if we don’t release fast, our competitors will get ahead of us. Unfortunately, that mindset is fraught with security risk as evidenced by the rising number of vulnerabilities in our software. Malicious actors can take advantage of these vulnerabilities to breach critical systems and exfiltrate sensitive data.

    Let’s not be too hard on ourselves, however. Security in a DevOps world is not an easy problem to solve. As we continue patching vulnerable code, new flaws emerge just as quickly. In essence, the security landscape is dynamic and continues to evolve. Solving a complex problem like this requires diversity of thought. In other words, we need to include people with different perspectives in the security conversation. Essentially, we need to build a collective mindset rooted in security culture. Security then becomes a collective responsibility rather than the responsibility of a few people.

    Now that we’ve agreed on the importance of collective responsibility, the logical question that emerges is, “How do I operationalize collective responsibility?” Pillar one addresses this question. We need to bring together our security and DevOps cultures. No longer can we talk about security or DevOps. It has to be both. This means security must be considered and addressed at every point in the software development and operations life cycles. Extending this further beyond the technical domain, security is fundamentally tied to business objectives, not left as an afterthought or considered a mere cost drain.

    Building a security-supportive culture involves three broad phases:

    • Phase One: Gain executive support and engagement
    • Phase Two: Design an effective program
    • Phase Three: Sustain the program

    What Does Pillar One Mean for DevSecOps Practices?

    Pillar one reinforces the idea that security responsibility cannot be limited to a few people. Just as software development is no longer an exclusively technical activity, security is no longer a compliance activity. This has a profound impact on DevSecOps practices. Here are just a few areas that are impacted by this shift in mindset and responsibility:

    • People across software development and operations activities must now consider security requirements
    • Security tools can no longer run separately from DevOps pipelines
    • DevOps teams need to understand security and how it applies to their roles
    • Security teams need to translate high-level policies into clear, atomic security requirements that can be implemented and tested

    How is Pillar One implemented?

    Implementation of pillar one touches on structural issues aimed at removing silos. There are many possible ways to build cross-functional teams. One approach is to have security embedded inside DevOps teams. Another approach is to integrate security as a support structure for DevOps teams. In either case, given the limited number of security professionals, a security champion can help bridge the gap between DevOps teams and security teams. A security champion ensures that the software being built and deployed takes security into account. To achieve this, it is important to set up a security champion for success:

    • Security must be their primary responsibility
    • They must be viewed as the security expert in engineering teams
    • They are responsible for mentoring and training developers
    • They can own threat and privacy models
    • They must have clear goals that are aligned with the business

    Setting up a security champions program without a clear sense of direction can lead to a lot of wasted time and effort. Collective responsibility rests on teams being able to communicate across functional silos and a security champion is an exemplar of that mindset.

    Speed Versus Security

    We live in a world where the rate of software development and deployment outpaces traditional security practices. This has come at a cost. Balancing both speed and security is the new norm. The right balance is dependent on each organization. One thing remains the same, however, and that is culture. We need a culture that is supportive of security and views it as a collective responsibility. This takes intentionality. Organizations need to get their executives involved and make sure the program has relevant elements to drive a security culture and has a clear path to business value.

  • CloudBees Acquires Neuralprints to Shift Compliance Left

    CloudBees Acquires Neuralprints to Shift Compliance Left

    At the online DevOps World 2021 conference today, CloudBees revealed it has acquired Neuralprints to provide the core technology for CloudBees Compliance, a real-time compliance and risk analysis platform that it will roll out in the first quarter of 2022.

    At the same time, CloudBees has enhanced the feature management capabilities of its namesake continuous integration/continuous delivery (CI/CD) platform to provide greater visibility into and control over feature flags that are now widely used to add new capabilities to applications.

    Prakash Sethuraman, chief information security officer (CISO) for CloudBees, said CloudBees Compliance will make it possible for DevOps teams to continuously enforce compliance policies as part of an effort to better secure their software supply chains. Those DevOps teams will be able to enforce compliance across code, binary artifacts, data, identity and infrastructure environments in a way that provides developers and IT operations teams with instant actionable feedback to enable issues to be addressed long before an application is deployed in a production environment.

    CloudBees Compliance is based on a mix of open source and proprietary technologies developed by Neuralprints and will be made available for on-premises IT environments as well as via a software-as-a-service (SaaS) application. The goal is to enable organizations to manage compliance as code as part of any effort to shift more responsibility for application security further left toward DevOps teams, said Sethuraman.

    CloudBees Compliance

    A survey of 500 C-level executives published today found nearly half (45%) admit that initiatives to secure their software supply chains are halfway or less-than-halfway complete. Nevertheless, 95% claimed their software supply chains are secure (95%), with more than half (55%) posting they are very secure.

    A full 93% said they are prepared to deal with an issue such as ransomware or a cyberattack on their supply chain. However, nearly two-thirds (64%) admitted they are not sure who they would turn to first if their supply chain was attacked; with 58% admitting that, if they experienced an attack, they have no idea what their company would do. An equal percentage (64%) said it would take more than four days to fix the problem if they did experience an issue.

    Almost all C-level executives (95%) said they think more about securing the supply chain now than they did just two years ago, and 92% said a security issue would impact their brand. A total of 83% said security issues cause their developers to drop everything to review code, with 82% noting that caused the organization to spend less time on innovation.

    On the plus side, 95% of executives said container images are checked for high or critical vulnerabilities, while an equal number said automation access keys are set to expire automatically. A total of 92% said their company only accepts commits signed with a developer GPG key, while 90% said dependencies to trusted registries are limited at their organization, while 89% said administrative access to CI/CD tools is restricted (89%).

    Of course, what C-level executives believe and what actually occurs inside an organization are not always one and the same. A series of high-profile software supply chain breaches resulted in a number of organizations reviewing their software supply chains. At the same time, the Biden administration has issued an executive order requiring all federal agencies to conduct similar reviews.

    One way or another, most organizations will soon find themselves embracing a wider range of DevSecOps best practices to ensure the integrity of software supply chains no matter how secure they may think their software development platforms are today.

  • DevOps World: Forget Doc, it’s All About Dev

    DevOps World: Forget Doc, it’s All About Dev

    This year for DevOps World, we’re heading back to the future. Doc Brown won’t be there with his souped-up time machine, but plenty of devs will. As the world is coming to realize, developers are keeping everything running, from the apps we use on a daily basis to check the weather, bank online or order food to the self-parking features on autonomous cars and artificial intelligence that’s augmenting human intelligence. Software and technology are the future, which means the future starts with the creative mind of the developer. 

    The theme of this year’s DevOps World show is “Building the Future of Software, Together.” For developers, this cannot ring more true: Across the globe, dev teams are working to code new software pipelines that will power the world’s next great innovations. We’ve already seen voyages into space and breakthrough life-saving medicines this year—what more do developers have in store for us?

    As we look ahead to DevOps World 2021 on Sept. 28 to 30, we are putting the focus on developers by offering a number of sessions to help sharpen their skills and prepare them to build the future of software. In particular, we are looking at some of the recent challenges that have been affecting code, including cybersecurity, scalability and CI/CD best practices. 

    On the security front, we’ve seen a number of cyberattacks dominate news headlines this year. As a result, companies are hyper-focused on securing their software pipelines and ensuring business and customer data are safe. Developers now need to double as the first line of defense for their organizations, ensuring their code and pipelines are as secure as possible. We’ve geared a number of sessions towards helping developers sharpen their security chops—from CloudBees customer success stories to tips for building more secure code. 

    As DevOps professionals know, software today is about continuous everything. We’ve designed a number of sessions to share best practices for CI/CD, progressive delivery and balancing speed, innovation and safety. Imagine if the DeLorean didn’t need the plutonium and just ran continuously—that’s what we’re hoping developers will learn and take away from these sessions!

    Lastly, scalability has always been a hot topic in tech. Startups continue to pop up everywhere and as these companies grow, they need to scale accordingly. We want developers to be scaling pros when they need to be, so we have a number of sessions (including keynote presentations) on scalability. 

    DevOps World is the event for developers looking to sharpen their skills, learn new abilities and network with other dev professionals. As we look to build the future of software together, the people making the magic behind the code will be driving changes and innovation, and we want to celebrate that.  While Doc Brown may be a fun character who goes back to the future, it’s dev where the future truly is. Register for DevOps World now!