devopsy.kinsta.cloud

Category: DevSecOps

  • Report: The State of Cloud-Native Application Security

    Report: The State of Cloud-Native Application Security

    The cloud brings tremendous capabilities in terms of increased deployment fluidity and automation. Along with cloud adoption has come the use of cloud-native tools built specifically for developing applications for this domain. However, cloud-native tools carry some nuanced security concerns, such as misconfigurations, known vulnerabilities and leaked secrets. As such, 83% of organizations recognize security as very important to their cloud-native strategy, according to a recent report from Snyk.

    Snyk’s State of Cloud Native Application Security report surveyed hundreds of IT professionals on their cloud-native security concerns. Below, we’ll pick out the top takeaways from the report, identify the most common trouble areas for cloud-native application security and see if there’s a correlation between deployment automation and higher degrees of application security.

    The Move to Cloud-Native

    Teams are moving to cloud-native tech, empowering DevOps with software-driven architecture and infrastructure-as-code (IaC). In this new cloud-native paradigm, 58% of production workloads are deployed as containers, 21% now are serverless and 50% use some form of IaC within the deployment process.

    Organizations are moving to cloud-native technology for a variety of reasons. For one, containerized software affords increased speed — 68% of organizations moved to containers for increased deployment velocity, the study found. This is followed by ease of management (at 67%) and reduced cost (43%). There is also the security imperative for adopting cloud-native tools; 36% of respondents cited security as a primary reason for moving production applications to containers.

    Top Cloud-Native Security Concerns

    While cloud-native technologies such as containers, Kubernetes, serverless and IaC enable more rapid development, they also bring unique security issues. The report found that misconfigurations and known unpatched vulnerabilities are by far the most common type of incidents among cloud-native environments. In fact, 45% of organizations have experienced an incident arising from a misconfiguration, followed by 38% due to known unpatched vulnerabilities.

    Other common cloud-native security incidents include secrets leaks, failed audits and malware. Interestingly, the study also found that data leaks by insiders are more common within organizations with higher degrees of cloud-native adoption. According to the report, 38% of organizations with high cloud adoption have suffered data leaks by an insider, whereas the figure is cut in half, at 17%, within organizations with low cloud adoption. Secrets like API keys must be managed carefully, especially as cloud-native tools force more dependencies. “The need for effective management of these kinds of artifacts is a key differentiator from the more centralized pre-cloud era,” the report noted.

    Automating Security Testing

    End-to-end deployment automation shows promise, yet is still at an early stage of maturity for most development teams. Though 95% of organizations use some kind of deployment automation, only about one in three organizations have an entirely automated deployment pipeline.

    Organizations with increased deployment automation tend to embrace a higher degree of security testing, as well. Highly automated pipelines are twice as likely to use security testing throughout their development lifecycle, found the report. Since incidents most commonly arise from misconfigurations and known vulnerabilities, automated scanning could help identify many cloud-native issues, comparing production code against databases of known exploits.

    So, when does this security testing occur? More often than not, it happens within the CI/CD pipeline. Over 60% of organizations perform security testing within the CI system. This is opposed to testing source code repositories or local IDEs and CLI tools early on in the development process. In terms of testing frequency, there is a wide range of executions. For those groups with high deployment automation, 70% test security daily or more frequently. Automated security testing seems to be functioning well, as 72% of fully automated teams find and fix critical vulnerabilities in under one week.

    The report also exposed an interesting disconnect with regard to security testing ownership. Only a small percentage of security engineers (less than 10%) feel developers are responsible for the security of the cloud-native environment and applications, whereas 36% of developers stated they are responsible for security. These figures may demonstrate the security onus shifting left toward the development side. Or it could underline changing attitudes as full-cycle development becomes more realistic. Regardless, teams will have to find clarity on roles to avoid some difficult conversations!

    Cloud-Native Security

    With the shift toward cloud-native strategies, security standards are rising to respond to new issues like misconfigurations. To address mounting application threats, increased automation could help shift security left—this and other reports clearly demonstrate a correlation between fully automated deployment pipelines and an increased security testing regimen.

    As a result of cloud-native adoption, 58% of organizations have increased their security concerns since adopting cloud-native tools. Part of this involves moving to a zero-trust approach across all infrastructure, whether internal or external facing. The report revealed that 58% of organizations are increasingly concerned with misconfiguration, 52% are increasingly concerned with insecure APIs and 43% are increasingly concerned about known unpatched vulnerabilities, while 41% are concerned about secrets leaks. Hopefully, these benchmarks will help you see how your organization stacks up in comparison to others.

    Snyk’s State of Cloud Native Application Security report questioned 600 experts in development, security and operations on cloud-native adoption and security practices. For more insights, view the study in its entirety here.

  • Google Proposes SLSA Framework to Secure Software Supply Chains

    Google Proposes SLSA Framework to Secure Software Supply Chains

    Google is proposing organizations adopt a framework for securing the integrity of software artifacts across a software supply chain.

    Kim Lewandowski, a product manager for open source software security at Google, said the Supply Chain Levels for Software Artifacts (SLSA) is based on an internal framework, known as binary authorization for Borg, that the company has been employing now for more than eight years to secure its software. Borg is the name Google attached to the platform for building and deploying applications upon which Kubernetes is based.

    In its current form, SLSA is a set of guidelines that identifies how to attain four different levels of application security. The goal, however, is to create a framework that will automatically generate auditable metadata that can be fed into policy engines to create a SLSA certification.

    The lowest level of SLSA requires that the build process be fully scripted or automated and generates metadata that enables provenance to be created. At the highest level, SLSA requires a two-person review of all changes made during a hermetic, reproducible build process. At the highest SLSA security level, organizations should be able to assure others that their software supply chain has not been compromised, said Lewandowski.

    Google

    In the wake of a recent series of high-profile breaches of software supply chains, the level of scrutiny being applied to how software is constructed has increased significantly. In theory, at least, developers have assumed more responsibility for application security as part of an overall shift left that provided them with more programmatic control over IT environments. As a result, cybercriminals are now focused on compromising either the credentials of developers as part of an effort to insert malware into application as it is developed, or they are trying to exploit vulnerabilities that developers have inadvertently created by programmatically misconfiguring infrastructure.

    DevSecOps best practices are, of course, being adopted to teach developers how to better secure their application environments. The issue is that not enough developers are learning how to secure applications fast enough. The volume of attacks against the software supply chain continues to grow at a rate that is now much faster than organizations can thwart simply by educating developers. In some cases, organizations are once again empowering cybersecurity teams to make sure software supply chains are secure regardless of the potential impact on the rate at which applications are being developed.

    Google is trying to promote adoption of SLSA as a framework for securing both open source and proprietary application code, said Lewandowski. There’s no silver bullet for securing software, but a framework that ultimately automates as many of the security processes as possible within the context of a DevOps workflow would go a long way toward hardening the software supply chain, noted Lewandowski.

    SLSA is being put forward as a response to a cybersecurity executive order issued by President Biden that, among other things, tasks the National Institute for Standards and Technology (NIST), an arm of the U.S. Department of Commerce, to consult with federal agencies, the private sector, academia and other stakeholders in identifying standards, tools, best practices and other guidelines to enhance software supply chain security. Given the level of dependencies that exist across those software supply chains, that executive order, to varying degrees, now applies to almost any entity that builds software for an organization that, on some level, interacts with the Federal government.

  • No More Hot Potato: How Collaboration is Key in Application Security

    No More Hot Potato: How Collaboration is Key in Application Security

    Technology is accelerating at an unprecedented rate and companies with little digital footprint or experience in application security are struggling to keep up. With more and more breaches and vulnerabilities being detected in applications, people are shifting blame like it’s a game of hot potato. But it doesn’t have to be that way.

    With Shifting Left Virtual Conference rapidly approaching, Rebecca Auguste sat down with the CEO of ShiftLeft, Manish Gupta, to discuss how developers and application security teams can better collaborate to increase application security efficacy. The two talked about ShiftLeft’s strategy, how innovation and security can be at odds with one another, adopting modern solutions and everything in between.

    What is ShiftLeft? 

    ShiftLeft is a next generation application security company. As companies are moving rapidly adopting the cloud, developing software ever faster so they can deliver features to their customers and drive ever increasing revenue, in that race we are starting to leave security behind because we are still using legacy tools. The idea is we need to shift left and we have to start fixing vulnerabilities as early on as possible in the process thereby reducing our cyber risk.

    Are innovations and security at odds with each other now? 

    Historically they have been. Use of legacy technologies in a modern pipeline forces customers to choose between being agile delivering feature functionality faster or getting better at security. At ShiftLeft we are starting to show through our customer successes that that choice doesn’t have to be that way. We can become more agile and we can become more secure.

    Here are some important statistics from ShiftLeft customers:

    1. If you’re doing automated enforcement in ShiftLeft you are fixing 91.8% of the vulnerabilities
    2. If you’re not doing automated enforcement but you’re using a modern solution like ShiftLeft you’re fixing 58% of vulnerabilities in the first sprint.
    3. If you’re still stuck with a legacy solution, your team isn’t fixing 60% of the vulnerabilities ever – forget if it’s the first, second or third sprint. It becomes technical debt. 

    So why aren’t people adopting modern solutions like ShiftLeft and ditching legacy solutions?

    Legacy solutions ask developers to slow down because they have to take a few hours to go scan and dump a long list of vulnerabilities. As the developer, seeing hundreds of vulnerabilities is like a deer in the headlights. Because it’s a mountain of work, it’s easy for developers to want to ignore the problems. The question shouldn’t stop at “what are our applications consisting of?” The real problem gets solved when we start asking what do our applications contain and what vulnerabilities do they have that can be exploited, therefore how quickly can we fix them. It’s all about moving to be proactive, not reactive.

    How can development and security teams better collaborate to increase the efficacy of security with applications and software? 

    It’s extremely important for us to realize that developers are not responsible for security. Developers are measured, they are compensated to deliver feature functionality on time and to provide that feature functionality with minimum bugs. But bugs are not vulnerabilities. There is a lot of talk in the industry that developers should become responsible for application security. We aren’t there today but we can eventually.

    There are two important application personas: 

    • Application security: Application security has a mile wide and inch deep knowledge of applications and who is compensated on app security improvements.
    • Developers: Developers have a mile deep but inch wide knowledge of software because they are so focused on their own code.

    Both personas are required because application security cannot fix vulnerabilities in applications, the developer must do that. But developers aren’t going to want to do that unless that work is prioritized by application security.

    Key takeaway? Collaboration is essential to application security.

    We need to create a workflow that allows application security to meet their end goals such as: What are the vulnerabilities of an application? What are the critical vulnerabilities? How can I provide these vulnerabilities to the developer in a developer workflow without asking them to go to a different console so they can fix vulnerabilities as quickly as possible? We need to start seeing a workflow that allows both application security and developer personas to work collaboratively to improve application security.

    Shifting Left 2.0 is a two-day virtual conference taking place from 9 a.m. to 2 p.m. PDT on June 22nd-23rd that dives deep into application security in the modern tech space. To register for free and to check out the full agenda, visit the Shifting Left 2.0 website.

  • Learning ‘The Third Way’ of DevOps – Continuous Improvement

    Learning ‘The Third Way’ of DevOps – Continuous Improvement

    I refer to the third way of DevOps–continuous experimentation and learning, as simply continuous improvement. In some sense, there is no way to learn the third way of DevOps because it is, by definition, a moving target. It does make sense to discuss what is needed to create a continuous learning organization for DevOps continuous improvement that builds on mastery of the first way and second way of DevOps.

    As indicated in my blog Learning ‘The Second Way’ of DevOps – Continuous Feedback and my prior blog Learning ‘The First Way’ of DevOps – Continuous Flow, it is clear many organizations are struggling to realize well-engineered DevOps, even the first way of DevOps, continuous flow.

    The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve the higher level of benefits that continuous feedback offers, when engineered well. Once the second way of DevOps is achieved, then an organization will naturally want to master the third way of DevOps, to sustain and grow their DevOps capabilities.

    DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Improvement

    There are no training resources dedicated solely to the third way of DevOps—continuous improvement. Many of the same resources as the first way of DevOps and the second way of DevOps do have some relevant information, though. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

    Why Is Learning Continuous Improvement Important to Engineering DevOps?

    The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Retention and development of highly skilled and hard to find experienced DevOps professionals and SREs makes it important to develop skills in-house.

    How Is Learning Continuous Improvement Accomplished?

    The following are recommended engineering practices for learning continuous improvement:

    • A continuous learning culture encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
    • Mentoring is an explicit program.
    • Retrospectives are structured to thoroughly analyze significant, unexpected events and determine solutions that will prevent the events in the future.
    • An active online library of DevOps and SRE training resources is maintained that tracks the latest and most innovative approaches to DevOps and SRE.
    • DevOps and SRE teams evolve their skills and advance their careers by engaging with industry thought leaders to continuously update training content.
    • Partner with trusted education and training partners ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
    • A portion of DevOps and SRE teams time is allocated for training and education.
    • Cross-team sharing of recommended engineering practices is proactively pursued using the concepts of Yokoten—proactive sharing of practices between teams.

    What Is Needed to Implement Learning Continuous Improvement?

    The following are recommended engineering practices for implementing a learning program for continuous improvement.

    • Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist).
    • Conduct a continuous feedback DevOps skills gap assessment.
    • Define a training strategy that best address the gaps and fits the needs and priorities of the organization.
    • Define a training budget that includes expenses and time allocations per role and skill.
    • Determine which skills and roles can be covered by inexpensive self-study resources.
    • Determine which skills and roles warrant more costly commercial training.
    • Identify training goals for each role.
    • Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.
    • Create a continuous learning culture that encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
    • Build an active online library of DevOps and SRE training resources that tracks the latest and most innovative approaches to DevOps and SRE.
    • Engage with industry thought leaders to continuously update con tent for DevOps and SRE teams to evolve their skills and advance their careers.
    • Partner with trusted education and training partners to ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
    • Put in place means to make training resources visible and available.
    • Set training goals for teams and individuals.
    • Put in place incentives and recognition programs for training.
    • Track training progress.

    Some of the best sources of DevOps training resources are listed below:
    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro.
    3. Udemy.com
    4. Recorded talks and publications of IT Revolution
    5. Books such as my own Engineering DevOps, by Marc Hornbeek.

    What This Means

    The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences, and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

    Organizations must approach DevOps training strategically and continuously to leverage training resources to best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • How to Analyze Your Code for Security Vulnerabilities

    How to Analyze Your Code for Security Vulnerabilities

    Shifting Left 2.0 is a two-day virtual conference taking place from 9 a.m. to 2 p.m. PDT on June 22nd-23rd that dives deep into application security in the modern tech space. Security experts share insights on topics ranging from how to measure AppSec success to what role AppSec plays in digital transformation. Software developers, security engineers, C-level business leaders and more can all benefit from the lively tech conversations at this free virtual experience. 

    Vickie Li, developer evangelist at ShiftLeft, teases her session at Shifting Left 2.0 in the Q&A below. Vickie and Suchakra Sharma, staff scientist at ShiftLeft, describe how to effectively review code for vulnerabilities and present tactics for performing an effective security code review on your applications on Wednesday, June 23rd from 10:10 a.m. to 10:40 a.m. PDT.

    You can find the full agenda and register for free at Shifting Left 2.0.

    To start off, why don’t you tell me a little bit about your role as a developer evangelist at ShiftLeft?

    My job as a developer evangelist is to help developers write more secure code. Here at ShiftLeft, we build and support ShiftLeft CORE, a security tool that helps developers find vulnerabilities in their code through SAST, SCA, and secret scanning. But a big component that goes into building secure software is to understand and remediate the vulnerabilities found by these tools. My goal is to help developers build more secure applications by learning the security fundamentals they need to write secure code and use security tools effectively.

    Your session is titled, “Intro to Code Analysis,” so I am curious what are some of the most effective ways to analyze your code for security vulnerabilities?

    I am probably giving away a bit of a spoiler here for my session with Suchakra. The most effective way of finding vulnerabilities in code is to use static code analysis, or to find security issues by analyzing source code. Techniques like dynamic analysis and penetration testing excel at finding exploitable vulnerabilities but often miss a large number of security issues. Static analysis, on the other hand, tends to be much better at finding as many vulnerabilities as possible.

    But conducting a manual code analysis on every single line of code is inefficient and not feasible in most cases. In this case, utilizing a SAST tool to scan the application and then validating the results afterward using manual code review would be the best action plan. 

    Code is really at the heart of building secure applications. With that in mind, how beneficial is it for developers to have a security mindset when writing code? 

    It is extremely crucial for developers to keep security in mind when building software. Security is a team effort by everyone: application security engineers, system administrators, managers, architects, and analysts. But when dealing with application security, developers are the ones who write vulnerabilities into code, and developers are the ones who have to fix vulnerabilities when they are found. So as developers, if we can keep security in mind during the development process, we can prevent vulnerabilities from being introduced into the code base, saving ourselves and our colleagues time and headache down the line.

    What type of security training or continuous learning practices should dev teams implement to help secure the code they write?

    Learning about security continuously is key to building secure applications. Developer security education needs to be efficient, engaging, and easy to absorb, and we need to introduce security training in a way that is relevant to everyday development work. By identifying security issues in a developer’s code, we can provide the context of the security issue and demonstrate the real-life importance of best practices.

  • Accurics Aligns DevSecOps Platform With GitLab

    Accurics Aligns DevSecOps Platform With GitLab

    Accurics today announced it has integrated its tool for discovering violations of security policies that occur when developers provision infrastructure as code with both the continuous integration and continuous delivery (CI/CD) platform and the static application security assessment testing (SAST) tools from GitLab.

    Om Moolchandani, chief information and security officer (CISO) and CTO for Accurics, said both integrations make it easier for developers to discover security issues earlier as part of a DevSecOps workflow using the company’s Terrascan tools.

    Many of the issues organizations are having with cloud security these days can be traced back to misconfigurations created by developers when configuring infrastructure using tools such as Terraform. Accurics created Terrascan to identify those misconfigurations.

    The integration with GitLab makes it easier to incorporate Terrascan into a DevOps workflow in a way that also aggregates data collected from both SAST and dynamic application security testing (DAST) tools, said Moolchandani. That approach effectively unifies what today are two separate cloud infrastructure and application development pipelines by enabling DevOps teams to employ threat scores to enforce security policies as code that are deemed too risky to deploy with block builds, he added.

    At the same time, the integration with SAST and DAST tools provides the context developers need to prioritize remediation efforts before applications are deployed in a production environment, noted Moolchandani.

    Organizations of all sizes are now trying to strike a balance between two conflicting agendas. On the one hand, infrastructure-as-code (IaC) tools such as Terraform have played a critical role in enabling developers to build and deploy applications faster. The issue is that developers lack the security expertise required to ensure infrastructure is secured properly at a time when cybercriminals are more aggressively seeking to compromise software supply chains. Organizations most likely won’t slow down the rate at which applications are being deployed to make sure software supply chains are not compromised. However, in the absence of best DevSecOps practices—which still are not widely implemented—there may be a backlash against shifting application responsibility left toward developers.

    The challenge that creates is most organizations don’t have enough security expertise available to review applications in a timely manner before they are deployed, which results in them hoping security issues will be discovered and remediated during the application update cycle before cybercriminals find a way to exploit a vulnerability.

    Of course, hope does not make for an application security strategy. Organizations will need to find ways to enable developers to better secure applications while simultaneously making it easier for cybersecurity teams to maintain a zero-trust IT environment that reduces the chances organizations will be breached via, for example, a phishing attack to steal developer credentials.

    Regardless of how DevSecOps workflows and zero-trust IT architectures are implemented, it’s clear organizations have run out of time to resolve longstanding security issues that are now making the kinds of headlines no one wants to see.

  • Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

    Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

    A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

    Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

    Cloud-Native Security Blindspots

    Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

    Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

    As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

    Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

    Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

    Faster Delivery, Harder Detection

    Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

    In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

    Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

    Who Owns Vulnerability Management?

    Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

    To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

    Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

    The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

    Cloud Use Requires Security Repositioning

    As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

    “The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

    The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

  • Learning ‘The Second Way’ of DevOps – Continuous Feedback

    Learning ‘The Second Way’ of DevOps – Continuous Feedback

    As indicated in my prior blog Learning the ‘First Way’ of DevOps–Continuous Flow, many organizations are struggling to realize well-engineered DevOps, even the ‘first way’ of DevOps – continuous flow.

    The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve greater benefits that continuous feedback offers when engineered well. DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Feedback

    There are no training resources dedicated solely to the second way of DevOps—continuous feedback. Many of the same resources used to learn the first way of DevOps have some relevant information, though. DevOps monitoring, release automation and security tools publications, articles and tool vendors are a good source. A DevOps expert who is experienced with mature DevOps can select the training information that is relevant to the specific continuous feedback tools and feedback metrics used by the enterprise.

    Why This is Important to Engineering DevOps

    Continuous feedback requires a mature understanding of DevOps concepts and practices. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security.

    How Is Learning Continuous Feedback Accomplished?

    The following are recommended engineering practices for learning Continuous Feedback.

    Roles and responsibilities are assigned to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist). Continuous feedback DevOps skills gap assessments are conducted periodically. Dev and Ops training strategies are designed to address gaps and priorities of the organization for DevOps continuous feedback. A training budget that includes allocations of expenses and time allocations per role exists to support continuous feedback. Continuous Feedback goals and SLAs are defined for each role.

    Recruiting job profiles match skill requirements for DevOps skills relevant for continuous feedback. Training resources are available and visible to those that need continuous feedback training. Training goals set for teams and individuals include goals for continuous feedback. Incentives and recognition programs support Continuous Feedback training. Continuous feedback training progress is tracked and visible.

    What Is Needed to Implement Learning?

    The following are recommended engineering practices for implementing a learning program for continuous feedback.

    Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., e.g., DevOps sensei, training PM, evangelist). Conduct a continuous feedback DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

    Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training Identify training goals for each role. Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.

    Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for training. Track training progress.

    Some of the best sources of DevOps training resources are listed below:

    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
    3. Udemy.com
    4. Recorded talks and publications of IT Revolution.
    5. Books such as my own “Engineering DevOps,” by Marc Hornbeek.

    What This Means

    To accomplish the benefits of the second way of DevOps—continuous feedback requires a commitment to continuous learning and mastering skills beyond what is needed for the first way of DevOps–continuous flow. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security. Organizations need a trained workforce to succeed with DevOps. Organizations must approach DevOps training strategically and continuously to leverage training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • Why API Quality Is Top Priority for Developers

    Why API Quality Is Top Priority for Developers

    It is no secret that web APIs have become increasingly important to the operation of modern businesses. According to RapidAPI’s Developer Survey and Insights report, 61% of developers used more APIs in 2020 than 2019, with 71% planning to use even more in 2021. We are no longer tied to a small number of monolithic service providers. Businesses tend to gravitate toward specialized managed services, such as billing and authentication, which are backed by APIs. Business models for new products and services are constructed based on APIs. Trust has become a necessity for APIs. APIs that perform consistently and with high quality earn trust, and those that do not are abandoned for a competitor.

    Why Does Quality Matter?

    If a market exists for an API, it’s a given that there will be competition. To remain competitive, APIs must build and maintain trust with their consumers; sales and marketing can only go so far. The highest quality APIs will inevitably capture the largest slice of market share. Quality isn’t a destination, either—it is a collection of goals that require continuous investment.

    What Does Quality Mean for an API?

    Just like the code that drives an API, the quality of an API itself is quantifiable. The following facets describe some broad categories used to measure API quality. The weight of each facet will vary depending on how business-critical the API will be when in production.

    Resilient. An API is resilient when it continues to operate in the face of adverse conditions. Can an API continue to operate (even at reduced capacity) if the database is down? How does it handle network traffic spikes?

    Robust. A robust API is liberal in what it accepts, but conservative in what it sends. Will it crash when presented with a poorly formatted request, or respond with instructions on how the caller can fix the problem themselves? Can the code be restructured without breaking the API contract?

    Secure. API security is vital in most deployments. Are efforts made to check for OWASP Top 10 Web App security risks? Are open source vulnerabilities known and addressed in a timely manner? Are secure endpoints gated with authentication?

    Discoverable. APIs that are well documented and well structured are much easier to consume and integrate with other services.

    Consistent. A consistent API is one that changes without negatively impacting existing consumers. Changes are backward compatible or versioned as new features are introduced. API consumers should know far in advance if a breaking change will be coming if it cannot be avoided.

    How Do I Get There?

    Processes, tools and, most importantly, culture, are the key to high-quality APIs. Let’s explore how we can approach each API quality facet.

    Resilient. Processes such as chaos engineering, load testing and manual quality assurance can uncover situations where an API is failing to handle unexpected situations. Deploying your API to a cloud provider with a compelling SLA instead of your own hardware and network shifts the burden of infrastructure resiliency to a service, freeing your time to build features for your customers.

    Robust. A comprehensive suite of automated tests isn’t always sufficient to provide a robust API. Edge cases, unexpected code branches and other unplanned behavior may be triggered by requests that were not considered when writing the test suite. Traditional automated tests should be complimented by fuzz testing to help uncover hidden execution paths. Canary and blue-green deployments can further expose your API to the real world in a limited manner and prepare for when even more unexpected requests will hit.

    Secure. API security is a moving target. It is expected that most APIs are built on layers of open source libraries and frameworks. Software composition analysis is a necessity to stay on top of zero-day vulnerabilities by identifying vulnerable dependencies as soon as they are discovered. OWASP guidance is a must-have—directing API developers to implement attack mitigation strategies such as CORS and CSRF protection. Application logic must be well tested for authorization and authentication.

    Discoverable. For REST APIs, the OpenAPI initiative provides a consistent language for describing the API. Many frameworks, such as Spring Boot, can even generate OpenAPI documentation directly from your code. gRPC-based APIs offer similar benefits by providing both instructions for accessing the API and building the clients to communicate with it. Adding support for GraphQL allows developers to connect multiple APIs together with consistent tooling. Whichever direction you choose, it is vital to keep API documentation up to date and accessible.

    Consistent. To be consistent, the API development process should make incompatible changes obvious. Code reviews can catch many breaking changes right at the source. API contract testing and integration testing can be used to discover API changes as part of the build. When working in a microservices environment, staging environments may alert engineers if an API change will cause problems before production.

    Quality Builds Trust

    According to the RapidAPI survey, 58% of executives said participating in the API economy was a top priority for their organization. The figure was even higher in certain industries such as telecommunications, where the number is 89%. Whether you are building APIs for internal use or for public consumption, your goal should be to earn the trust of API consumers. Investing in the culture, tools and processes to build quality APIs will pave the way to building and maintaining that trust.

  • HashiCorp Increases Terraform’s Enterprise Appeal

    HashiCorp Increases Terraform’s Enterprise Appeal

    During the online HashiConf Europe conference today, HashiCorp debuted the general availability of a 1.0 release of HashiCorp Terraform along with updates to HashiCorp Terraform Cloud service.

    Meghan Liese, senior director of product marketing for HashiCorp, said in both cases HashiCorp is moving to enable organizations to better secure and govern IT infrastructure-as-code provisioned using open source Terraform tools.

    Version 1.0 of HashiCorp Terraform provides access to a stable application programming interface (API) that will foster interoperability and simplify future upgrades.

    The Terraform Cloud service, which eliminates the need for IT teams to set up and manage a Terraform platform, adds workflows enhancements to the Terraform Cloud that include the ability to publish curated modules to a private registry, enhancements that make it easier to visualize elements of a workspace and a preview of an ability to check with third-party tools related to a Terraform run.

    Overall, the goal is to make it simpler for organizations to compose, collaborate and reuse infrastructure-as-code using modules and the public and private registry options, said Liese. The public registry already has more than 5,000 modules. Terraform Cloud now offers a native workflow to publish modules from the public registry directly into an organization’s private registry.

    Terraform, of course, has been widely employed since it first debuted in 2014. There have been 15 major updates prior to the release of Terraform 1.0, which is intended to provide a foundation that ensures backward compatibility between releases going forward.

    In some instances, Terraform can be too much of good thing. It has considerably accelerated the rate at which IT infrastructure can be provisioned within the context of a DevOps workflow. The challenge, though, is developers often lack the security expertise required to prevent infrastructure from being misconfigured at a time when cybercriminals have become more adept at scanning for those vulnerabilities. To enable IT teams to prevent those misconfigurations, HashiCorp makes available both an enterprise edition of Terraform as well as its Terraform Cloud service. Terraform Enterprise is used by more than 1,200 enterprises, while Terraform Cloud has more than 120,000 users that execute more than 30,000 runs per day.

    It’s not clear if security concerns might one day lead to a backlash against the concept of shifting more responsibility left toward developers to improve productivity. In some cases, developers are simply deploying more insecure applications faster. HashiCorp is making a case for Terraform platforms that allow centralized IT teams to exercise more control over how infrastructure is provisioned as code. The need for that approach is becoming more pronounced, as organizations not only employ Terraform to provision cloud infrastructure but also on-premises IT environments.

    Regardless of how infrastructure is provisioned by developers, security of infrastructure, both inside and outside of the cloud, remains a priority as more workloads than ever are deployed. In effect, the attack surface that needs to be defended has dramatically expanded. Of course, the best security issue of all is the one that never happened because infrastructure is being provisioned right the first time and every time thereafter.