devopsy.kinsta.cloud

Category: DevOps Practice

  • A Seven Point Checklist for Getting SAST Right

    A Seven Point Checklist for Getting SAST Right

    With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

    In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

    Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

    With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

    1. Deep Language Support: C/C++, Java, C#, etc.

    Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

    2. Compiler and Embedded OS Platform Compatibility

    Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

    3. Actionable Alerts

    For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

    4. Built-In DevOps Integration

    The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

    5. Flexible Deployment

    Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

    6. Developer-friendly UI

    Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

    7. Standards

    Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive),  DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

    Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

  • Software Supply Chain Risk Management: A 2023 Guide

    Software Supply Chain Risk Management: A 2023 Guide

    Software supply chain risk management (SSCRM) refers to the process of identifying, assessing and mitigating risks associated with third-party software components and services that are integrated into software products. SSCRM involves understanding the potential vulnerabilities that may arise from these components and taking measures to reduce the risk of exploitation or compromise to the software system or end-users.

    Why Software Supply Chain Attacks are Becoming More Common

    Software supply chain attacks have become common due to several factors: 

    • Larger attack surface: The increased use of third-party software components and services in software development has expanded the attack surface for cybercriminals. This means that attackers can exploit vulnerabilities in these third-party components to gain access to the larger software system. 
    • Rise of open source: The proliferation of open source software has also contributed to the rise of supply chain attacks as attackers can inject malicious code into open source repositories, which can then be used by developers in their software products.
    • Difficulty to detect: Detecting supply chain attacks can be challenging since attackers often use legitimate-looking code that may be difficult to distinguish from normal code. This can make it difficult for traditional security measures to detect the attack. Additionally, the attack may not manifest itself until much later, making it even harder to trace back to its source.
    • Automation: Supply chain attacks are also becoming more sophisticated through the use of automation. Attackers can use automated tools to scan for vulnerabilities in third-party components and inject malicious code into them. This means that they can quickly and efficiently compromise a large number of software products.
    • Evasion techniques: Attackers can evade traditional security measures through techniques such as code obfuscation and encryption. This makes it difficult for security measures to detect malicious code, which can easily slip through undetected.
    • Sophistication: Supply chain attacks are becoming more challenging to combat due to the use of advanced malware techniques to change shape. Attackers can use polymorphic malware that can change its code and behavior to avoid detection. This means that even if the malware is detected, it can quickly change its form to evade detection in the future.

    Supply Chain Security and DevSecOps

    DevSecOps is an approach that integrates security into all stages of the software development process. Adopting DevSecOps practices can help businesses manage supply chain risks by building security into their software development and delivery pipelines. 

    Continuous integration/continuous deployment (CI/CD) pipelines are a key component of DevSecOps, as they allow developers to rapidly test and deploy code changes while ensuring that security and compliance requirements are met.

    Here are some ways DevOps tools in the CI/CD pipeline can help manage supply chain risks:

    • Automating security testing: DevSecOps enables businesses to automate security testing throughout the software development life cycle, including during the development, testing and deployment phases. This can help identify and mitigate security vulnerabilities early in the process, reducing the likelihood of supply chain risks.
    • Continuous monitoring: DevSecOps enables continuous monitoring of software and infrastructure, providing real-time visibility into the security posture of the supply chain. This can help identify and respond to security threats quickly and effectively.
    • Secure coding practices: DevSecOps encourages the use of secure coding practices, such as input validation, access control and error handling, reducing the likelihood of supply chain risks.
    • Risk management: DevSecOps incorporates risk management into the software development process, ensuring that supply chain risks are identified, assessed and managed effectively.

    Tools and Solutions to Help Manage Supply Chain Risks

    Supply Chain Risk Management (SCRM)

    SCRM solutions are software tools and services that help organizations manage and mitigate supply chain risks. These solutions provide visibility into the supply chain operations, identify potential risks and enable organizations to take proactive measures to mitigate these risks. 

    They may include features such as supplier risk assessments, real-time monitoring of supply chain operations, analytics and reporting and incident response planning. SCRM solutions are often available as a service (SaaS) and can help organizations to enhance supply chain resilience, reduce disruption and ensure business continuity.

    Software Composition Analysis (SCA)

    Software Composition Analysis (SCA) is a software security practice that involves identifying and managing open source and third-party components used in the development of software applications. SCA tools scan the software codebase, detect and report the presence of third-party and open-source components and identify known vulnerabilities in these components. 

    SCA helps organizations to identify and manage risks associated with third-party components, including license compliance, intellectual property infringement and security vulnerabilities. SCA is an essential component of SSCRM and can help organizations to ensure the security and integrity of the software products they develop and distribute.

    Third-Party and Supplier Risk Management

    Third-party and supplier risk management software is designed to help businesses manage the risks associated with their third-party vendors and suppliers. This software provides tools and resources to identify, assess and manage the risks associated with third-party relationships.

    Here are some features of third-party and supplier risk management software:

    • Supplier management: The software provides tools to manage supplier relationships, including supplier performance monitoring, supplier compliance and supplier risk assessment.
    • Risk assessment: The software enables businesses to assess the risks associated with their third-party relationships, including financial risks, operational risks and reputational risks.
    • Compliance management: The software helps businesses comply with regulations and standards, such as GDPR, HIPAA and ISO 9001.
    • Data analytics: The software uses data analytics tools to help businesses identify trends and patterns in third-party data, enabling them to anticipate and mitigate risks.
    • Incident management: The software provides tools to help businesses respond to and manage incidents related to third-party relationships, such as data breaches or compliance violations.

    Best Practices for Software Supply Chain Risk Management

    The following are some best practices for managing supply chain risks.

    Identifying Supply Chain Threats and Potential Weaknesses

    The first step in managing supply chain risks is to identify potential threats and vulnerabilities in the supply chain. This involves conducting a comprehensive risk assessment that considers all potential sources of risk, including geopolitical factors, natural disasters, cyber threats and other disruptions. The risk assessment should consider the entire supply chain, including all vendors, suppliers and partners.

    During the risk assessment, organizations should identify the critical components and services that are essential to their operations. They should also evaluate the potential impact of a disruption to these critical components and services, including the financial, reputational and operational impact.

    Establishing a Supply Chain Risk Management Framework

    After identifying potential threats and vulnerabilities, organizations should establish a supply chain risk management framework that outlines the policies, procedures and controls required to mitigate these risks. The risk management framework should be aligned with the organization’s overall risk management strategy and should include the following components:

    • Risk management policy: This policy should outline the organization’s approach to supply chain risk management and define the roles and responsibilities of key stakeholders.
    • Risk assessment procedures: These procedures should describe how the organization conducts risk assessments, including the criteria used to evaluate risks and the frequency of assessments.
    • Risk mitigation controls: These controls should outline the specific measures the organization will take to mitigate identified risks.
    • Incident response plan: This plan should describe the steps the organization will take in the event of a supply chain disruption.

    Continuously Monitoring Risks

    Once the supply chain risk management framework is in place, organizations should continuously monitor supply chain and third-party risks and take proactive measures to mitigate them. This includes establishing a patching cadence to ensure that all software components are up to date and protected against known vulnerabilities.

    Organizations should also implement endpoint security controls, such as antivirus software and intrusion detection systems, to protect against malware and other cyber threats. Network security controls, such as firewalls and access controls, should be implemented to protect against unauthorized access to systems and data.

    Web application security controls should also be implemented to protect against web-based attacks, such as SQL injection and cross-site scripting. This includes conducting regular vulnerability assessments and penetration testing of web applications.

    Promoting a Culture of Awareness

    Finally, organizations should promote a culture of awareness among all stakeholders, including employees, vendors, and suppliers. This includes providing risk awareness training to employees, so they understand the risks associated with the supply chain and the steps they can take to mitigate these risks.

    Organizations should also communicate their supply chain risk management policies clearly to vendors and suppliers so they understand their obligations and responsibilities in managing supply chain risks. This includes conducting due diligence on vendors and suppliers to ensure they meet security standards and policies.

    Conclusion

    Managing supply chain risks is a critical task for organizations that rely on third-party vendors and suppliers to deliver goods and services. These risks can arise from a range of sources, including geopolitical factors, natural disasters, cyber threats and other disruptions.

     To effectively manage these risks, organizations need to adopt best practices such as identifying threats and potential weaknesses, establishing a supply chain risk management framework, continuously monitoring risks and promoting a culture of awareness.

    As we look ahead to 2023, it is clear that software supply chain management will continue to be a priority for organizations across industries. With the increasing complexity of software supply chains and the evolving threat landscape, organizations must remain vigilant in their efforts to identify and mitigate potential risks.

  • Survey Surfaces Application Modernization Challenges

    Survey Surfaces Application Modernization Challenges

    A survey of senior IT leaders suggested the level of confidence in application modernization projects that many organizations initially had is now starting to wane.

    The survey polled 200 senior IT leaders at organizations with more 1,000 employees and was conducted by Global Surveyz Research on behalf of EvolveWare, a provider of platform for automating application modernization processes. The survey found 70% of respondents reported they were confident or very confident in their understanding of their applications when they prepared for modernization. However, that level of confidence dropped to 41% at the planning stage and even lower (28%) at the point the project began, the survey found.

    More than half of respondents (51%) are already experiencing or anticipating critical issues that need to be addressed immediately, the survey found. The top areas of importance are understanding the parts of the code that contain business policies (47%), database access details (43%) and understanding the complexity (40%).

    EvolveWare CEO Miten Marfatia said the survey makes it clear organizations are encountering issues associated with capturing tribal knowledge that has been lost mainly because the teams that initially built an application are no longer with an organization. In fact, the survey found a full 81% of respondents reported they currently have or anticipate challenges hiring or retaining talent to support legacy applications. Nearly half (46%) currently don’t have enough talent available to manage legacy applications.

    The survey found the primary reason these initiatives are launched is to boost employee productivity (40%), followed by retiring mainframe infrastructure (37%), reducing the dependency on legacy code (36%), reducing maintenance costs (30%), improving customer experience (29%) and cloud migration (22%). Most of these projects are generally focused on critical applications (55%) as well as applications that have few or no dependencies (55%), the survey finds.

    The primary success metrics for assessing these projects, however, are improving customer experience (46%), the readiness to migrate to the cloud (46%) and meeting the performance requirements of the modernized application (45%).

    Less than a third of respondents (31%), however, reported having access to modern tooling. More than half would like to automate code transformation and business rules extraction (BRE) while 40% would like to automate documentation.

    Nearly two-thirds (64%) said freezing code during the modernization process would have significant business and financial consequences, with 59% noting that finding a way to modernize applications without freezing code is at the top of their technology wish list.

    Application modernization efforts usually have multiple goals. IT teams are usually motivated by a desire to reduce the amount of time and effort required to support legacy applications that are generally less efficient than modern applications. In addition, many IT teams are also looking for ways to reduce the total cost of running those applications, especially during uncertain economic times. Business leaders, meanwhile, are funding digital business transformation initiatives that typically require some level of modernization of legacy applications.

    Regardless of motivation, it’s apparent many IT teams initially underestimate the amount of effort required to achieve those goals.

  • Dylibso Releases Tool for Tracking and Validating Wasm Modules

    Dylibso Releases Tool for Tracking and Validating Wasm Modules

    Dylibso today made generally available a system of record for tracking, investigating, searching and validating modules built using the WebAssembly (Wasm) binary instruction format.

    Fresh from raising $6.6 million in additional funding, Dylibso CEO Steve Manuel said Modsurfer exposes the internal contents to enable developers to debug Wasm modules and ensure compatibility with runtime environments.

    Modsurfer provides development teams with a console for accessing a fully auditable database of modules indexed for search and debugging. In addition, development teams have the ability to extract critical information from binary formats in a way that can be integrated with DevOps pipelines. In effect, Modsurfer provides application development teams with X-ray vision into previously opaque Wasm modules, said Manuel.

    Dylibso previously developed Extism, an open source universal plug-in system that supports multiple programming languages used to build Wasm modules. That reduces the level of effort required to integrate Wasm modules and provided the foundation upon which Modsurfer was created, noted Manuel.

    Wasm, at its core, is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The World Wide Web Consortium (W3C) drove the development of Wasm as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to create a set of universal binaries that could work on any platform without modification.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries between them. One of the issues of that approach is that it becomes relatively simple for malware to infect all the components of an application.

    It may be some time before WASM becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are finally starting to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. That’s not only critical in terms of overall application developer productivity; it also has major implications in terms of streamlining the management of DevOps workflows as it becomes easier to both initially deploy applications and continuously update them.

    As organizations continue to review their application development practices to better secure software supply chains, it’s also become apparent that legacy approaches to building applications are fundamentally flawed. Rather than attempting to reengineer processes to encourage developers to better secure applications, it may be more effective to change the way applications are built. After all, considering all the processes required to secure legacy development approaches, it may be cheaper and easier to adopt a new method for building applications that lowers overall risk, said Manuel.

    Of course, the amount of Wasm expertise that exists in the developer community is still limited. However, DevOps teams should expect to see more Wasm modules moving through DevOps pipelines as Wasm tooling continues to improve.

  • Data APIs: Realizing the Future of Data Warehousing

    Data APIs: Realizing the Future of Data Warehousing

    Data is the currency of business in today’s digital economy, with organizations collecting mountains of data from their customers, products and services. Enterprises are increasingly turning to data warehouses to store this valuable enterprise data and to make it useful and actionable. Data APIs–both GraphQL and REST–are emerging as a tool to power frictionless and high-quality integrations between applications/services and data in enterprise data warehouses. But what exactly is driving this shift toward using APIs on top of data warehouses? In this article, I will talk about the drivers behind the rise of data APIs on data warehouses, challenges with current approaches to building, operating and scaling data APIs and how organizations can address those challenges.

    The Rise of Data APIs

    Data APIs enable organizations to create powerful integrations between applications without having to go through lengthy development cycles or write complex code. As a result, businesses can deliver improved user experiences faster than ever before by quickly connecting disparate applications and services together using intuitive REST or GraphQL endpoints. Because these endpoints are standardized across multiple systems (e.g., REST or GraphQL), developers don’t have to learn new languages or coding techniques every time they want to connect two different applications together. This makes it much easier for developers to work with multiple systems simultaneously while still ensuring that all applications remain connected via one interface–the API endpoint itself.

    Challenges With Current Approaches

    Despite all these advantages provided by Data APIs, there still remain a few challenges that organizations need to consider when building out their own solutions. For example, many existing approaches require manual setup processes, which can be extremely time-consuming and tedious for developers working with multiple systems at once. In addition, many existing solutions only allow for limited query functionality, which means that more complex queries may not be possible without additional coding or manual setup processes being performed. Finally, some existing solutions require an extensive amount of organizational resources in order to build out a full-fledged solution—time that could be better spent on more important tasks like product development or customer service initiatives.

    How Organizations Can Address These Challenges

    Fortunately, there are now tools available that make it easy for organizations to quickly build out powerful data API solutions with minimal effort required from their developers or IT staff members. These tools provide pre-built templates that can be used as a starting point for any integration project while also allowing users to customize their own solution based on specific needs and requirements without having to write any code themselves. Additionally, these tools allow users access to advanced query functions such as joins across multiple tables so they can get the most value out of their databases without compromising either speed or security either. Finally, these tools also include powerful monitoring capabilities so users can ensure that their data APIs remain running smoothly at all times, no matter how much traffic they receive.

    Benefits of Using an API for Integrating Cloud Data Warehouses

    When it comes to integrating cloud data warehouses into your application or service, there are several advantages that come with using an API as opposed to traditional methods such as manual coding or ETL tools:

    • Increased Flexibility: By leveraging an API, you are able to access data from multiple sources quickly and easily without having to manually code every integration yourself. This also allows your application or service more freedom when it comes to accessing additional data sets in the future; all you need is an existing API connection in place.
    • Improved Security: Since APIs are designed specifically for secure communication between different systems, they offer enhanced levels of protection against malicious attacks such as DDoS attacks or unauthorized access attempts. You can also add additional layers of security by implementing authentication protocols like OAuth or JWT tokens on top of your existing API connection.
    • Enhanced Performance: APIs can be designed with specific performance optimizations in mind; this means that you can create custom solutions tailored towards the exact needs of your application or service which will ultimately result in improved end-user experiences and higher engagement rates from customers who interact with your product or service regularly.

    Data warehouses have become an essential part of modern digital businesses due to the sheer amount of valuable enterprise information they store. However, traditional approaches can often lack the flexibility or scalability needed in order for businesses to stay competitive in today’s ever-changing market environment. This is why smart organizations are using data APIs on top of them for quick integration among disparate applications/services along with advanced query capabilities.

    By leveraging tools designed specifically for this purpose, companies can easily overcome current challenges associated with building out their own solutions while still getting maximum bang for their buck when it comes down to successful implementation and operation over the long term.

  • Postman Releases Tool for Building Apps Using APIs

    Postman Releases Tool for Building Apps Using APIs

    Postman today made generally available a visual tool infused with artificial intelligence (AI) that makes it simpler to build software by invoking application programming interfaces (APIs) found on its network.

    Shamasis Bhattacharya, chief software architect for Postman API, said Postman Flows makes it possible to use a low-code tool to build software using tens of thousands of APIs that can be found on the Postman API network.

    The goal is to reduce the amount of toil required to build applications of moderate to medium complexity in a way that doesn’t require developers to have deep programming expertise, he added.

    Instead, developers are presented with “blocks” that they can drag and drop to create an application and deploy the associated workflows. Postman Flows leverages AI to manipulate data returned by APIs using a natural language interface that reduces the level of technical acumen required to create those workflows.

    That approach provides developers with a reactive experience that is embedded within a visual tool, noted Bhattacharya.

    Many developers still have a natural bias toward writing code, but as demand for applications continues to increase, Postman Flows provides a means to significantly increase developer productivity, said Bhattacharya. There may still be instances where writing code is required, but as developers save more time using Postman Flows, many of them will switch over to a visual tool to build software faster by essentially gluing blocks together, he added.

    There’s naturally a lot of focus these days on developer productivity during uncertain economic times. More organizations than ever are dependent on software, but their ability to hire armies of developers is limited. Low-code tools have emerged to provide a means for accelerating application development, but Postman is now looking to apply that concept directly to the network of curated APIs that it provides to application developers.

    The one thing that is certain is that as the pace at which applications are being built increases, the number of them running in production environments will steadily increase. DevOps teams will find themselves maintaining a wide range of applications that were constructed using both procedural code and low-code platforms.

    In the meantime, IT organizations may want to start evaluating which types of applications lend themselves to being built by development teams that may not require as much experience writing actual code. Much of the application development backlog organizations are struggling with today could be reduced using tools that automate a wide range of development tasks. That should free up developers with more advanced skills to work on more complex applications. That approach might also reduce developer turnover as much of the fatigue associated with building more routine applications is reduced.

    Regardless of how applications are built, there will be a need to manage them in production environments. DevOps teams may soon be able to focus more of their time and expertise on optimizing application performance in production environments versus continuing to shepherd massive amounts of code through continuous integration/continuous delivery (CI/CD) pipelines.

  • What DevOps Leadership Should Look Like

    What DevOps Leadership Should Look Like

    Implementing DevOps has become a major focus, but the practice’s attempt to provide organizational support and streamline production systems simultaneously leaves developers with no clear hierarchical structure. We know we need DevOps and we know it helps, but we also know that without proper leadership or structure, it can be misunderstood and undervalued. To build a strong collaborative culture, DevOps leadership, like most other leadership roles, requires a different type of skillset—a skillset that isn’t always prioritized in software development. The ability to understand programming languages, to be versatile and be attentive to detail will take a developer far in their career, but once they’re in a management position, what is needed to be an effective DevOps leader?

    First, what does an effective DevOps leader look like? To start, they need to lead. But to lead a DevOps team, it’s important to not only understand development—including reasonable goals and how to accomplish challenging tasks—but a DevOps leader needs to be able to create an environment that fosters collaboration between teams.

    This is why a DevOps culture is a core value for any high-performing DevOps team. This is due to the cross-functional nature of the practice. The stages of the DevOps cycle (plan, build, test, deploy and manage) rely on different teams with different skill sets.

    Build a Culture Of Ownership and Teamwork

    To effectively collaborate, a strong cross-functional culture of ownership, teamwork, intensity and smart application is needed.

    Clarity can transform a team, and it starts with ownership. Ownership is essential for cross-functional DevOps teams to understand their roles and what they are responsible for. In order for clarity to exist, leaders need to provide clear direction and guidance. It is a leader’s responsibility to set realistic goals and offer support. Group trust is built when a team has a common goal and clear roles and responsibilities are identified.

    Ownership is the foundation of teamwork, and with it, team members can see their individual contributions to a project and can celebrate their successes together. This teamwork then breeds collaboration, improved performance and a cohesive dynamic within the team’s culture.

    Lead With Strategic Intensity and Smart Application

    A DevOps leader can empower their team through ownership and teamwork, but we can’t forget the value of knowing the right level of intensity for a project. Leaders need to understand a situation, the context and how to approach it strategically to avoid burnout and bitterness. They must know when to apply intense sprints and when to pull back and move resources—a leader must know how to play smart with the resources they have.

    Use Soft Skills

    People management skills can be overlooked in a lot of leadership positions. For example, we might see it when a startup chooses a CTO or an engineering lead position based on seniority or developer skills without regard for their ability to actually manage people or their desire to be in such a position. Often, the person in charge of a DevOps team is given this role because of their previous development accomplishments, but they lack the necessary soft skills of communication, conflict management and/or teamwork. Using the four principles above can help accelerate the foundation of culture as well as help compensate for a leader’s lack of soft skills

    DevOps leaders need soft skills. Soft skills include the ability to think critically and project manage while having enough emotional intelligence to inspire, motivate and retain a team of smart engineers. Every leader needs to be able to see their team’s strengths and weaknesses, listen and influence and further develop their members to succeed. The challenge for this role is that, to be successful, it takes both technical expertise and soft skills and knowing how to balance the two.

    Unfortunately, soft skills haven’t been prioritized in the training and career development of most software engineers. Only recently have soft skills been seen as a differentiator in the engineer hiring process or seen as a value-add to an organization. For years, technical skills took precedence and we ignored the areas that would take a software engineer to the next level – the soft skills that will lead to leadership. But it’s a bigger problem; employers say most college grads aren’t learning these soft skills in school.

    Remember the Not-so-Secret Sauce

    Soft skills empower a leader to thrive both within a DevOps team and in collaboration with other departments. The ability to work across teams can exponentially improve business operations. A strong DevOps leader can offer solutions and problem solve for internal issues and customer-facing problems. They are able to bring DevOps into new areas of the company in a strategic and effective way. Collaboration requires working with others, seeing the bigger problem, understanding the business goals and using soft skills to get things done.

    It’s the not-so-secret sauce that makes all the difference when running a powerful DevOps team. A culture of collaboration starts with the leader. A leader’s relationship skills can increase the likelihood of bigger budgets, more tools and recognition. DevOps leaders can build a strong team by leveraging the soft skills within themselves and their team members, applying the right level of intensity and encouraging a culture of ownership, teamwork and collaboration. If these things are missing, whether DevOps or another team, the unit will fall apart.

    This is why a DevOps leader needs to take personal ownership and responsibility for the success of their team and see motivating others, setting a standard of operational excellence and representing the DevOps team as an integral part of their role. Luckily, there are resources to learn and exercise these skills so every leader, newly appointed or veteran, can ensure their team can excel.

  • HPE to Acquire OpsRamp to Gain AIOps Platform

    HPE to Acquire OpsRamp to Gain AIOps Platform

    Hewlett-Packard Enterprise (HPE) this week revealed it is acquiring OpsRamp to gain access to a platform for embedding artificial intelligence in IT operations (AIOps).

    Latha Vishnubhotla, chief platform officer in the office of the CTO for HPE, said the company would embed the machine learning technology developed by OpsRamp across its entire portfolio in addition to leveraging it to automate IT processes the company manages via its GreenLake service for HPE customers.

    Ultimately, HPE will be applying machine learning across the entire IT stack, including applications, to reduce the total cost of IT, she said.

    The acquisition of OpsRamp is expected to close in the third quarter of this year. Terms of the deal were not announced, but it comes at a time when more organizations are getting comfortable with AIOps.

    A recent OpsRamp survey polled 138 IT leaders working for enterprise IT organizations and 127 representing managed service providers (MSPs) that generate at least $25 million in revenue and have more than 500 employees. The survey found the primary reason organizations are embracing AIOps is to improve service and application availability and performance (60%), followed closely by automation of operations (58%) and processes (54%).

    The survey found that the greatest IT operations challenge for enterprises in 2023 was automating as many operations as possible (66%), followed by driving greater efficiency and productivity of IT operations teams and processes (61%). Application-to-infrastructure dependency mapping is the top incident management challenge (64%), the survey found.

    The primary operational benefit cited was reducing open incident tickets (65%), followed by reducing mean-time-to-discovery (MTTD) and mean-time-to-remediation (MTTR), tied at 56%, and automation of tedious tasks (52%).

    In general, organizations are choosing one of two AIOps paths, said Vishnubhotla. Some are waiting to evaluate the recommendations made by the AIOps platform before implementing, while others are looking to completely automate processes so they can focus more of their time and effort on application development and deployment, she said. In much the same way a driver of an autonomous vehicle learns to trust the AI over time, there is a similar transition occurring with AIOps, noted Vishnubhotla.

    The challenge is that it takes an AIOps platform a few months to learn an IT environment. The more dynamic that IT environment is, the longer that process can take. At the very least, however, AIOps platforms have the ability to automate many low-level IT tasks today that conspire to increase the amount of toil DevOps teams would otherwise encounter.

    It’s difficult to determine how pervasive AIOps may be within IT environments, but there is no doubt as organizations look for ways to manage IT at scale, there will be increased reliance on automation. Most organizations can’t afford to continue to hire armies of IT personnel, especially as the global economic outlook remains uncertain.

    In fact, one of the benefits of an AIOps platform is that, unlike an employee, it does not take any days off or suddenly decide to take another job. It also, for better or worse, doesn’t forget anything once it’s been learned. As such, it’s now only a question the degree to which AIOps platforms will be trusted over time to manage increasingly more complicated IT tasks.

  • Oracle Makes Java 20 Platform Generally Available

    Oracle Makes Java 20 Platform Generally Available

    At an Oracle DevLive Level Up event, Oracle today announced the availability of a Java 20 update that makes a range of innovations more accessible to application development teams.

    Georges Saab, senior vice president of development for the Java Platform and chair of the OpenJDK Governing Board for Oracle, said the latest version of the venerable programming language builds on previous extensions made to the Java development kit (JDK) that exemplify how the pace of Java innovation is now increasing.

    Specifically, seven JDK Enhancement Proposals (JEPs) are now supported in Java 20, including OpenJDK project Amber for record patterns and pattern matching for switch expressions and statements; enhancements from OpenJDK Project Panama to interconnect Java Virtual Machines (JVMs), features related to Project Loom that streamline the process of writing, maintaining and observing high-throughput, concurrent applications and a Function & Memory application programming interface (API) and Vector API.

    Oracle also revealed Java 20 is supported by Java Management Service, an Oracle Cloud Infrastructure (OCI) native service that provides a single pane of glass to help organizations manage Java runtimes and applications on-premises or on any cloud.

    Finally, Oracle is making available an Oracle Java Universal SE Subscription that provides access to a pay-as-you-go offering that includes entitlement to GraalVM Enterprise, the Java SE Subscription Enterprise Performance Pack, access to the advanced features of the Java Management Service and the flexibility to upgrade at any pace an organization prefers.

    Oracle Java Standard Edition (SE), GraalVM Enterprise and the Java SE Subscription Enterprise Performance Pack are also now available free of charge on OCI.

    Despite the number of programming language alternatives that exist, many enterprise IT organizations remain committed to Java. Rather than opting to retrain developers, it’s simply been more cost-effective to enable developers to continue to build applications using a programming language they already know.

    Java itself, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under an open source OpenJDK license. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications that are being modernized. As part of those efforts, the rate at which Java applications are being deployed in the cloud has substantially increased.

    As part of those efforts, many organizations are currently in the process of shifting to Java 17. It’s not clear how many organizations will skip Java 17 and jump to Java 20 from previous versions of Java, but DevOps teams should expect to be supporting a wide range of versions of Java for years to come.

    In fact, most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a programming language that has persevered through two decades and appears to have enough staying power to stick around well into the next.

  • Awareness of Software Supply Chain Security Issues Improves

    Awareness of Software Supply Chain Security Issues Improves

    A global survey of 167 software professionals suggested that, while there is a lot more awareness of application security issues, the adoption of DevSecOps best practices is still not pervasive.

    The survey, conducted by Chainguard, the Eclipse Foundation, the Rust Foundation and the Open Source Security Foundation (OpenSSF), found that just over half (51%) of respondents are either concerned or are extremely concerned about software supply chain security.

    In addition, only a third of respondents (33%) reported they are familiar with the Supply-chain Levels for Software Artifacts (SLSA) framework for building more secure applications. Well over a third (36%), however, said they had never heard of it.

    Only a quarter of respondents (25%) reported that their team always signed built artifacts, the survey found.

    The survey identified the most challenging issues developers are encountering and found they are reproducing builds (64%) followed by creating hermetic builds that are isolated from other software libraries (62%).

    Mikaël Barbero, head of cybersecurity for the Eclipse Foundation, said while awareness of software supply chain issues is higher, it’s apparent that other priorities are still getting in the way of adoption of DevSecOps best practices. For example, software bills of materials (SBOMs) may generate a lot of headlines, but their adoption remains mixed, he added.

    John Speed Meyers, a security data scientist for Chainguard, noted that incentives still need to change; too many managers that hire developers still emphasize performance and delivery times over application security. Many developers, as a result, still tend to view cybersecurity as an obstacle to be overcome or worked around rather than a core capability that they will be graded on, he added.

    In theory, as responsibility for application security shifts left toward developers, overall cybersecurity will improve. Most developers, however, have little to no cybersecurity training, so the odds they will be able to resolve these issues are low. Instead, many organizations are either trying to embed cybersecurity professionals within DevOps workflows or, at the very least, deputize at least one developer to advocate for cybersecurity within those teams.

    Regardless of commitment level, it’s apparent that organizations need to address everything from locking down developer environments to thwart phishing attacks to ensuring application builds are not inadvertently infected with malware. The challenge organizations face is both technical and cultural, so the amount of effort required should not be underestimated.

    In the meantime, organizations should expect to see cybercriminals increase their attempts to compromise software supply chains. Infecting malware into software components that will be used by multiple downstream applications is, from their perspective, one of the most efficient means of wreaking havoc. Right now, organizations make it too easy for cybercriminals to compromise application environments.

    Organizations should also recognize that tolerance for insecure applications is also declining, as evidenced by the National Cybersecurity Strategy put forward by the Biden administration. It’s not so much a question of whether organizations that create software will be held liable for application security issues as much as it is to what degree.