devopsy.kinsta.cloud

Category: Blogs

  • Continuous Delivery Without Exception

    Continuous Delivery Without Exception

    Continuous delivery (CD) and all the other continuous things—continuous integration (CI), continuous testing, continuous deployment—have become the new mantra of DevOps. CI/CD adoption typically starts with agile development teams working on new or well-funded systems. But what about the rest of the world and all of those “other” applications, under-funded IT teams are responsible for supporting? Can or should continuous delivery be a reality for all applications?

    The answer is a resounding yes! No application is an island. Every application is subject to change, whether it be code changes, patches to the OS, changes to the supporting databases or changes to the infrastructure it is running on. Without a regulated pipeline to deliver changes quickly across all systems, organizations expose themselves to unforeseen risks and escalating maintenance costs.

    No matter how new or well-funded an application is today, it will soon become one of many other applications that have to be secured, patched, updated and maintained as part of an organization’s IT estate. For example, consider all those “hot-new” Windows IIS sites built in the early 2000s now sitting on Windows Server 2008/R2, which reached end of life Jan. 14, 2020. Unsupported operating systems are not only costly but they also provide prime targets for cyberattacks, (the Bluekeep Vulnerability being just one of many examples).

    The term “technical debt” was introduced in 1992 by Ward Cunningham to describe what happens when we fail to adequately maintain what he calls “immature” code:

    “Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program un-masterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of anunconsolidated implementation.”

    Organizations Must Navigate Complexity

    The “J-Curve of Transformation” included in the “The State of DevOps, Dora Report” visualizes the challenges large, complex organizations face when automating delivery pipelines. Teams first target high-profile projects and quick wins and then see a drop-off as they’re faced with mounting complexity and technical debt.

    Nowhere is complexity and technical debt more relevant than when it comes to mission-critical commercial-off-the-shelf (COTS) applications Microsoft SQL. Manual controls, layers of process and siloed support teams are all commonly associated with these types of apps. The term “bi-modal” IT is commonly used to describe the variance in delivery processes used for these types of apps versus custom apps being released as part of continuous delivery pipelines.

    Not only are COTS apps handled in this “bi-modal” fashion, but they are also the “forgotten” and the “hidden” applications—the forgotten being legacy applications still in use but no longer being actively developed, and the hidden being all the applications needed by IT to run IT operations. To succeed at continuous delivery, organizations need to apply standardization across delivery pipelines for all teams and environments including complex, forgotten and hidden applications.

    Complex: Mission-Critical COTS Applications

    Large, mission-critical applications such as Microsoft SQL present unique challenges to teams focused on enterprise DevOps, but successful CD pipelines are possible. Teams must first recognize that packaged applications are fundamentally different than custom-built applications. Similar to older applications (which many packaged applications also are), the fundamental challenge is creating an automated way to build packages that can then be consumed by the pipeline. Success here also requires additional intelligence about the underpinning proprietary services and technologies supporting the packaged application.

    Forgotten: Legacy Applications

    There are myriad reasons why older applications present major challenges to organizations trying to achieve continuous delivery: technical debt, lack of resources, required refactoring, operating platform dependencies and a fear of business disruption, to name a few. Updating these apps many times requires individual acts of heroism, involving an abundance of manual efforts in which runbooks are individually updated, shadow sessions are invoked and the impact on dependent systems is typically not known until the update hits production.

    Getting started with continuous delivery requires creating an automated build package that can then be deployed via the pipeline to the preferred destination—cloud, on-premises or hybrid. If the application and all of its dependencies have been successfully abstracted from the underlying operating system and infrastructure and packaged accordingly, it can be consumed into the pipeline and deployed anywhere without having to refactor or rewrite the application.

    Hidden: IT ‘Owned’ Applications

    The Digital Age has led to an exponential growth of applications used by the business (websites, distribution, POS, etc.) as well as third-party applications/tools used by IT teams to build, test, deploy, manage, secure and monitor those applications. In many cases, these applications have become just as mission-critical as the business applications they’re supporting, but they’re not typically treated as “applications” by the business.

    In many cases, they remain completely hidden from the business, with little understanding of the value they provide. Often there is no clear owner for the application, different teams use the application in different ways, updates and patches are handled ad hoc, and expertise is limited to a few individuals within the organization (who take the knowledge about the application with them when they leave).

    Ultimately, third-party applications used by IT need to be managed like any other application. If not, delays in release and production failures caused by changes not properly tested in pre-prod will happen.

  • KubeCon Coverage: Incentivizing the DevSecOps Culture

    KubeCon Coverage: Incentivizing the DevSecOps Culture

    Just as DevOps set to de-silo development and operations teams, the DevSecOps movement is bringing security to the same table. A shift-left security mindset is permeating much discussion of late.

    Cyberattacks are on the rise in the era of COVID-19 and cybersecurity has become paramount to arm business-critical applications. Furthermore, new regulations have emerged to protect personally identifiable information (PII). A new cybersecurity awareness feels quite apparent throughout the tech spectrum. As a result, security policies are poised to integrate more directly within the process of engineering and deploying applications.

    Nonetheless, while DevSecOps feels necessary to implement at this critical hour, it does present challenges. Primarily of which is a significant cultural shift. Uniting security and development isn’t as easy as it sounds, especially when faced with rigid enterprise bureaucracy. Plus, how can an organization incentivize DevSecOps if developers fear security tools will slow down their workflows?

    The DevSecOps panel at the recent KubeCon + CloudNativeCon North America 2020 brought together leaders in the DevSecOps arena to advise introducing a security-first mindset to DevOps. Dan Papandrea, field chief technologist at Sysdig, led this super-informative panel. It featured:

    • Emily Fox, DevOps Security Lead, NSA
    • Peter Bosch, Cisco
    • Sunil James, HPE
    • Christian Weichel, Gitpod
    • Nicolas Chaillan, U.S. Air Force

    Below, I’ll cover some of the key insights garnered from the event. To summarize, the panel identified how policy-first tools and open source initiatives are placing security controls within IDEs and CI/CD pipelines. And what will it take to get everyone onboard? It appears that transparent tooling automation, making security adherence natural and a new wave of security-aware employees will be critical components in the future era of DevSecOps.

    What is DevSecOps?

    First off, to get a better picture, what exactly is DevSecOps? And why has it come about?

    In a previous article, we defined DevSecOps with six traits: security automation, security culture, de-siloing IT, shifting security left and security as an enabler (not a stalling force).

    The KubeCon panelists seemed to echo all of these points. Fox described DevSecOps as “a term used by organizations to ensure their DevOps approaches have a security-first mentality.” To her, this means placing security automation within workload environments.

    DevSecOps is something new. For most organizations, security isn’t baked into the standard development processes—it historically hasn’t been the first priority, Chaillan said. DevSecOps is changing that, adding continuous monitoring, zero trust enforcement and reducing the overall attack surface.

    The move toward continuous release is also an impetus for DevSecOps. “Our cadence of delivery has been quickened,” said James. All organizations now feel pressure to deliver value to customers rapidly. An interesting byproduct of building security-first, he said, is “the ability to create the consistency and speed with which you can actually offer these capabilities.”

    Another cause for DevSecOps is the sheer imbalance in the workforce. On average, the number of developers far outweigh the number of security folks, noted Bosch. So, DevSecOps could scale security across an organization more effectively than human power could.

    Bosch also is hopeful DevSecOps could put an end to time-consuming bureaucracies stalling an agile security process. “Developers used to write code and wait for free months to open a firewall.” This may have been standard operating procedure decades ago, but in the age of continuous everything, enterprises must evolve how they handle IT security policies. “By uniting security with developers, we bring speed, robustness, avoid OWASP issues, and build applications that better contribute to the bottom line,” he said.

    Finally, embracing DevSecOps is a significant commitment. The combination of culture and technology is essential, noted Weichel. As we infuse security testing into CI/CD pipelines and make everything security-first, he said, we indeed undergo a cultural shift—it’s something that permeates everything.

    Challenges in Implementation

    Companies attempting to introduce DevSecOps may run into a few challenges, including instilling the culture, implementing regulatory compliance and finding the right blend of open source and propriety tools to get the job done.

    Bosh is no stranger to sluggish enterprises and the systemic change required to introduce DevSecOps. In these environments, changing companywide antiquated processes may require executive sponsorship. “By and large, it’s mostly culture,” he said, yet acknowledged a vast divide between the two groups: “How do you convince security do get out of their comfort zone? And how do you convince developers to get out of theirs?”

    There is also developer experience to consider: Developers often view security tools as limiting their ability to deliver code quickly. Perhaps the biggest challenge to overcome is improving the experience of working alongside new security policies. If new practices are causing more pain, instead of automating pain points away, DevSecOps could suffer.

    Outside of team dynamics, there are also technical hurdles involved when introducing and enforcing legal regulatory requirements. “Getting any sort of compliance baked into CI/CD pipelines is a challenge,” said Fox. Part of the problem is that the tooling to enforce such requirements isn’t there yet. “Cloud-native is continually evolving and security is constantly playing catch up,” she noted. “It’s an ongoing challenge.”

    Incentivizing the DevSecOps Culture

    Employees need incentives to change established habits. With the above challenges in mind, how can organizations create incentives to adopt DevSecOps? Well, outside of monetary incentives or straight up demanding it, incentivizing that security culture could happen in a few different ways, the panelists noted.

    To Fox, it’s about “making security transparent to the developers.” You want developers to quickly build and deploy secure applications without the need for intensive cybersecurity training. Thus, the tools and processes must be as transparent and usable as possible. DevSecOps is possible “if you make it second nature,” she said.

    Another way to consider DevSecOps culture is the end performance. If customers are happy, this is a positive gauge. James said he has witnessed CIOs at a few organizations using customer satisfaction scores as a guiding light for not only the business but for security effectiveness well.

    Bosch similarly stressed an indirect incentive about overall company performance. “Companies that really embrace DevSecOps leads to better code,” said Bosch. This leads to more robustness, higher speed, and better-operating enterprises. Co-building a thriving success could be ample incentive alone for those who have the whole team in mind.

  • OpsRamp Makes AIOps Platform Simpler to Configure

    OpsRamp Makes AIOps Platform Simpler to Configure

    OpsRamp today took the wraps off an update to its namesake artificial intelligence platform for IT operations (AIOps) that makes it easier for IT organizations to declaratively configure the software-as-a-service (SaaS) platform.

    Ciaran Byrne, vice president of product management for OpsRamp, said the goal is to enable IT teams to embrace AIOps without having to hire a small army of consultants.

    The OpsRamp Fall 2020 Release adds a revamped user interface that provides access to a set of wizards that discover the assets that make up a specific IT environment and subsequently automate the configuration process.

    OpsRamp has also added curated dashboards that enable IT teams to launch queries using the Prometheus Query Language (PromQL), developed for the open source monitoring tool being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    The latest edition of the AIOps platform also adds monitoring capabilities for containerized workloads and Kubernetes clusters. In addition, IT teams can monitor other cloud services including AWS ECS, Azure Functions, Azure Hyperscale (PostgreSQL) and Azure SQL Managed Instance.

    OpsRamp has also added IT process automation capabilities that can be triggered by alerts, updates to resources or on a recurring schedule. An OpsQ bot now also recommends automation workflows. Alternatively, IT teams can require manager approval before a process is launched.

    In general, Byrne said the goal is to improve the mean time to value for an AIOps platform managed by a team of data scientists who have extensive experience applying machine learning algorithms to IT processes.

    Efforts to automate IT have increased sharply now that most IT staff are working from home to help combat the COVID-19 pandemic. However, few organizations are able to set up and configure an AIOps platform in an on-premises IT environment on their own, especially now that outside consultants are no longer being invited to spend weeks working on projects, Byrne said, noting a SaaS-based approach makes it possible for IT organizations to take advantage of an AIOps platform while continuing to work from home.

    In general, the downturn in the economy has increased interest in AIOps because IT staff ranks are either remaining the same or shrinking even as IT environments continue to become more complex. Longer-term, Byrne said it’s not clear that hiring Level 1 and 2 IT administrators will be sustainable as AIOps platforms continue to automate processes.

    DevOps teams, of course, are especially keen to automate as many IT processes as possible, which is why there is a high correlation between organizations that have embraced DevOps and early adopters of AIOps.

    It may still be a while before AIOps is widely employed, but it’s now only a matter of time before machine learning algorithms are pervasive across IT. The challenge now is figuring out where the handoff between man and machine for managing IT ultimately will lie.

  • How to Make a Self-Healing IT Infrastructure a Reality

    How to Make a Self-Healing IT Infrastructure a Reality

    In 2019, enterprises worldwide reported that every hour of infrastructure downtime cost them an average of $301,000- $400,000. If a system is down for five hours, that’s $1.5 million lost—and that’s on the low end. Five hours of downtime can impact companies for months down the road. It’s in the hands of DevOps practitioners to ensure systems are up and running and budgets are kept in line. But if they don’t have the proper tools on hand that allow them to juggle their responsibilities while adding value to the business, it makes their jobs that much more difficult—or, dare I say, impossible.

    Teams simply can’t afford to go offline to fix incidents, but neither can they afford to manually sift through data to find the root cause. By automating the incident management process, developers have more time to focus on building new products and capabilities that drive revenue. With a self-healing IT infrastructure, teams can tackle these issues before they become larger issues costing millions of dollars.

    Imagine you’re running to catch a bus and your heart rate increases, but when you sit down, it doesn’t come back down to a normal rate. This could quickly become a much larger, even fatal issue. In this instance, the body should “self-heal” to get back to a normal rate. On a similar note, a self-healing IT infrastructure allows teams to quickly get back on track by fixing issues before they become a $1.5 million problem.

    Let’s look at how DevOps practitioners can turn a self-healing IT infrastructure into a reality.

    Self-Healing Infrastructure Needs Observability and AI

    Observability is the practice of collecting deep data from applications and services to provide insights through three core components: logs, traces and metrics. While these three components are essential to a self-healing infrastructure, they are most powerful when used together. Similar to our senses of sight, hearing and touch, they each tell us something different but are equally important. When combining the power of all three, development teams can determine where, when and how an incident occurred and take action as needed.

    We all know the pain of traditional monitoring tools. They don’t surface immediate issues or identify root causes. They rely too heavily on developers to interpret and analyze immense amounts of data then sift through it in a tedious and time-consuming process requiring extra budget for more human power, and extra time to identify and remediate incidents. Using today’s cloud-native self-service approaches to combine observability and artificial intelligence, teams can set up tools themselves that automate the process of gathering and correlating metrics, logs and traces at machine speed to provide a complete, intelligent and actionable picture of what’s happening and why. And that’s where a self-healing IT system starts.

    The Future Is Within Reach

    By ingesting observability data, applying AI to analyze that data and create insights around root causes, then leveraging automation in a closed-loop, dev teams can not only see what’s happening but also take action on it for remediation. When this closed-loop process is done intelligently at machine speed, that’s when self-healing becomes a reality.

    The idea of a self-healing IT infrastructure doesn’t have to be a distant vision. In fact, the democratization of cloud computing and advanced data science have put the required observability technology within reach of teams of any size with any budget. When artificial intelligence and observability come together, DevOps practitioners can operate less and innovate more.

  • Open Source Software and the Tragedy of the Commons

    Open Source Software and the Tragedy of the Commons

    With many eyes looking at code, “All bugs become shallow,” as software developer and author Eric Raymond called Linus’s Law in action. This is one of the reasons behind the popularity of open source: the volunteer communities working to improve and update the code.

    And according to a Purdue University study, Linus’s Law does, in fact, work. Open source communities regularly issue patches faster than their proprietary software counterparts. However, Linus’s Law only works when there are enough eyes on the code. And there’s no guarantee that the community behind any given open source project will continue maintaining the code.

    Of the 1,200+ codebases examined for “2020 Open Source Security and Risk Analysis” (OSSRA) report, 88% contained open source components that had had no development activity in the last two years.

    Now let’s take a trip back in time to glean a few lessons that history has offered. You see, in the early 19th century, “free lunches” were a popular saloon promotion. Patrons had to buy a beer (or drink or alcoholic drink of their choosing) to wash down whatever food the barkeep offered. And there’s the catch.

    Profits on whiskey and beer sales more than compensated the saloon for putting out the free lunch spread, which often was little more than soup, crackers and problematic pickled eggs. There’s a price for everything—whether evident or not.

    With popular open source code, this price of a free lunch has increased the pressure on those maintaining it—those who handle bug reports, feature requests, code reviews, code commits, etc., for their so-called “free” software. Increasingly, as open source grows in popularity, the price of free lunch has been developer burnout and the abandonment of their open source projects.

    It’s the tragedy of the commons in action—a resource growing so much in popularity that it can’t remain viable unless the community shifts to sustenance rather than exploitation. Witness the Twitter thread started by James M. South, creator of several popular open source solutions, who bemoaned the fact that, “#ImageSharp passed 6 million downloads this weekend and I’m a lot less happy about it than I probably should be.”

    South goes on in several follow-up tweets, “Over 5 years of development there have only been 98 collaborators, 23 of which have made more than 10 commits. … It’s not about money, it never was and never will be, it’s about sustainability.”

    Too few people—and their organizations—who rely on open source software are contributing to the projects they use. If you’re a developer and have a favorite open source component, you can contribute to its development through development, sharing your modifications, bug reporting, crowd-funding, letting the developers know how you are using it and helping others get started. That last may be the most important thing you can do for any open source project—helping build a user community large enough to sustain the project.

  • strongDM Extends Access Management as Code Efforts

    strongDM Extends Access Management as Code Efforts

    strongDM today announced it has added an application programming interface (API) and software development kits for Go, Java, Python, Ruby and other programming languages for involving the single sign-on (SSO) capabilities of its infrastructure access management platform, in addition to adding support for command-line interfaces (CLIs) exposed by cloud service providers.

    At the same time, strongDM has integrated its namesake platform with third-party secrets management tools such as Vault from HashiCorp as well as platforms such as PagerDuty’s incident management platform and Slack messaging tools.

    The access management platform can now also support any internal web applications and database platforms including DB2i, CitusDB, Oracle 11g, 12c, and 19c, Sybase ASE and IQ.

    Finally, the company has made enhancements to existing protocols including Mongo Atlas, SSH certificate-based authentication and SSH port forwarding, and added support for Windows remote desktop protocol (RDP) network-level authentication (NLA) and integration with other SSO tools such as Auth0 and VMware Identity One.

    Company CEO Elizabeth Zalman said strongDM, unlike other SSOs, is designed from the ground up to be incorporated within a developer’s workflow. The goal is to enable developers to manage access as code in the same way they manage infrastructure as code, she said.

    In general, access management is usually the last stage of automation to be addressed by DevOps teams. However, with most DevOps teams now working from home to help combat the spread of the COVID-19 pandemic, there has been a sharp rise in the number of organizations seeking to automate access management as an alternative to managing virtual private networking (VPN) software, said Zalman.

    Historically, many IT organizations have relied on Microsoft Active Directory (AD) or the Lightweight Directory Access Protocol (LDAP) to manage access. As an alternative, strongDM has been making a case for its platform since 2015. The company recently raised an additional $17 million in funding and claims to have more than 100 customers using its platform in production environments, including Peloton, SoFi and Betterment.

    It’s unclear whether DevOps teams are extending their existing workflows to include access management. However, as DevOps teams grow weary of using custom scripts to extend those workflows, Zalman said eventually they’ll look for a more consistent approach to automating access management. A major factor in that decision is the fact that most employees won’t be coming back to the office in the same numbers they did prior to the pandemic, even after a vaccine is discovered and distributed.

    At the same time, more DevOps teams are moving to embrace best DevSecOps practices, which inevitably will encompass access management. In fact, as part of that transition, it’s probable most DevOps teams will conclude the way access is currently managed is simply too antiquated to continue.

  • DevSecOps Implementation: Source Composition Analysis

    DevSecOps Implementation: Source Composition Analysis

    This is the second installment in this series on DevSecOps. Read the first installment, on Static Analysis, here.

    One of the better additions to security in recent years is source composition analysis (SCA). The purpose of SCA is to sit in the gap between static analysis and dynamic analysis to help you find issues introduced by included libraries, projects, etc. While effective, source composition analysis is only available on open source libraries and packages, which are the highest growth areas of external sources in any project. If we are purchasing a product to include in our application, we take our time and compare and contrast to make certain we have the right thing. If there is an open source option, we just drop it in. Particularly if the option is popular—little thought goes into using MySQL database in Python or its equivalent in other languages. If a Python project uses MySQL or MariaDB, it is needed, so it is grabbed and used.

    The growth of source composition analysis is a great boon to security. Having a tool that takes care of monitoring vulnerabilities in code that is included across the board, sometimes in very uncontrolled ways, means vulnerabilities are known before the app goes live or the new release is published. Security staff doesn’t have to try to ferret out what is included in projects across the org and then cross-reference those findings with the National Vulnerability Database (NVD) or project-specific lists. The tool takes a load off security’s shoulders and makes certain developers know the risks their open source software (OSS) usage represents. The best tools notify developers when including vulnerable open source and can be configured to require approval before a vulnerable OSS library/module can be included.

    With all of that said, let’s talk about what to look for. There are some similarities with our static analysis list, but some distinct differences also. Disclaimer: As mentioned in the Static Analysis blog, this is very high-level. The research we’ve done at Accelerated Strategies Group went much deeper than we can present in a series of blogs; this is just to help you understand the top-level issues and get started down the road to a solid DevSecOps plan:

    • Language Support: This goes beyond most users’ needs in static analysis. One of open source’s strengths is building off other projects. It is often the case that Python will call C modules and some Python projects even include Go libraries. This means your chosen development tools aren’t so much relevant for scanning as the development tools chosen by projects—and their included projects.
    • Depth of Checking: Which brings us to, “How deep does the tool go?” Nesting of open source libraries can be deep and complex, with the project an application uses directly just the tip of the ice-berg. Ideally, look for a tool that answers the, “Is this even ever called?” question. It’s a good start to alert on included OSS projects and it is far better to alert on ones where the vulnerable parts are called from somewhere in the hierarchy.
    • Where to Run: The market is slowly moving to support both cloud-based and local scans. Make certain your organization’s needs are met by the vendor’s offerings.
    • When to run: Some vendors bundle source composition analysis in with their static analysis IDE plugins; others have developers run the scan command line; others offer source composition analysis at the build step—when the app is together in one place; still others offer all of the above. Again, make certain the needs of your organization are met.
    • What Is Detected: As with most security tools, this is normally a base comprised of public sources (NVD, OWASP), with add-on detection from other sources. Know what those other sources are and what they offer: that is one major difference between most products.
    • Reporting: Make certain that vulnerability reporting has everything you need. Consider the possibility that it alerts on a vulnerable OSS library in source file insecure.go. All other uses of that vulnerability need to be visible in some way from that report. Removing the reference from insecure.go is useless if reallyinsecure.go also includes it and has an exception from management to keep the inclusion.
    • Reporting Integration: While scanning OSS usage and vulnerabilities the usage introduces is important, so also is the ability to see these results side by side with static, dynamic and even interactive scans so the overall security posture of the application can be evaluated.
    • Frequency Versus Cost: OSS vulnerabilities come in unpredictable patterns, with several dropped in a week after no important ones were seen the week before. You are going to want to run these scans frequently enough to feel comfortable with your security posture, but depending upon licensing, each run might cost your company money. Make sure you understand your needs and costs associated with meeting them.
    • Licensing: The newest feature to be added to these tools is the ability to list all licenses of all included libraries so that someone can review and see what risk is introduced to the organization from licensing. Many open source projects are licensed so that commercial use is limited; this tool puts all the various licenses together so an organization can evaluate litigation risk based upon license usage. The best tools allow you to also enter proprietary license information so that all licensing relevant to an application is reviewed together.

    These tools help improve security posture by automating what is an increasingly complex manual process and bringing in vulnerability sources that security (be they secure developers or dedicated security staff) would have to manually look for. They enable shifting OSS vulnerability resolution left, allowing your team to become more agile and proactive. Make certain the tool chosen is the right one for the organization.

    As I said in the last installment, you all are keeping the lights on in a truly difficult time, making a tough job look easy. Don’t let vulnerabilities that can be caught easily with these tools but might stay hidden without stop your great work. They are relatively easy to install and configure; once you have them, you have on-demand OSS vulnerability scanning and if you are like most organizations, OSS is a huge piece of your software infrastructure. Keep rocking it, and make sure you are covered for OSS vulnerabilities and licensing.

  • Two-Part Training Required for Developers to Slay the Security Beast

    Two-Part Training Required for Developers to Slay the Security Beast

    Developers’ defensive qualities are only as good as the training they receive

    The playing field between the heroes and villains in cybersecurity is notoriously unfair. Sensitive data is the new gold, and attackers adapt quickly to circumvent defenses, exploiting security bugs large and small for potential paydirt.

    The volume of code being produced is too great for security experts—who are becoming increasingly scarce—to contend with, and the rising cost of data breaches is proof that something has got to give. Fortunately, for the sake of our digital safety and the sanity of CISOs everywhere, the DevSecOps movement is helping to bring developers on the security journey from the beginning of the software development process. They are being recognized as the first line of defense against cyberattackers, with the power to eliminate common vulnerabilities at their fingertips.

    However, their defensive capabilities are only as good as the training they receive, and that is yet another gauntlet for security teams to run. For many developers receiving on-the-job training in secure coding, their key challenge is staying awake during mind-numbing, hands-off activities that are neither effective nor inspiring them to keep security front of mind. Soulless video courses aren’t getting us there, token annual ‘tick-the-box’ events are a waste of time, and nobody is winning against the potential malicious threat actor waiting to jump on a small window of opportunity.

    At this stage in our industry, we have worked out that contextual, hands-on education that is delivered in relevant programming languages and frameworks, with challenges that mimic those a developer might come across in the real world, is a far more engaging approach.

    This is phase one of a developer’s quest to help AppSec gurus slay common vulnerabilities, but phase two is where scenarios must get real for a supercharged, security-aware defensive force.

    Scaffolded Learning Is Critical in Adult Education

    When it comes to extracurricular courses or on-the-job training, it is often overlooked that adults bring with them a certain level of experience and existing knowledge. Good training adds to this foundation and is structured in a way that allows for deeper understanding and faster autonomy in the learning process.

    Scaffolded education is a potent, positive method of learning that seeks to activate and enhance prior experience while continuing to build new skills—in manageable chunks—that allow the learner to tackle increasingly difficult tasks with more confidence. Typically, it is a methodology best served with healthy portions of demonstration, visual aids and student-led exploration.

    If we tie this approach back to developer security training, it comes as no surprise that the dynamic, learn-by-doing method has long been preferred over the drudgery that is theory-based static learning. They are free to be the masters of their domain and should see that their time is being well-spent.

    In that sense, learning to code securely in a hyper-relevant, contextual environment is key, but the ‘level up’ from this step is to see an exploit of vulnerable code in action. With the context of front-end and back-end views side-by-side, there is a tangible link between actions taken during the coding process and what an attacker can potentially do with cut corners, misconfigurations or accidents that are not caught and remedied.

    Move From Recall to Application for a Truly Preventative Security Approach

    Experiencing the impact of security vulnerabilities firsthand is a vital piece of the education puzzle, and it’s a fairly rare beast, even with the most modern security training options for developers. The foundational work spent on honing skills in spotting and remediating vulnerabilities and recalling that experience to eliminate the same bugs in code as it is being written is extremely important, but it’s not the whole picture. Seeing how vulnerable code is exploited by a malicious actor adds a powerful layer of context, one that really drives home the importance of securing code and applying hard-earned security knowledge to close every window of opportunity.

    It is generally accepted that developers don’t love security, and they have even less affection for security training. Their experiences with AppSec specialists can be very frosty, and the rework caused by the security team bouncing vulnerable code back to developers for remediation is the bane of their existence. To an engineering team that is already spread thin, security is someone else’s problem, not their priority, and a hindrance to their natural creativity and primary objective of building features. However, there is simply too much code, too many breaches and too much risk to the world’s data for this mindset to continue.

    A functional DevSecOps process has developers working in harmony with security teams right at the beginning of the software delivery life cycle (SDLC). Likewise, the opportunity for applied learning, where they can interact with a simulated exploit and see the impact of poorly secured code, goes a long way in getting developers on the same page as those pesky AppSec people (who aren’t so bad after all).

    Interactive Learning Prepares Developers for the Boss Fight

    At the time of writing, there were two major breaches reported in a seven-day period: Razer announced that more than 100,000 sensitive data records had been exposed, while office supplies retailer Staples also reported a similar data leak. More than a billion sensitive records have been exposed so far in 2020, and this worrying trend shows no signs of slowing down. Simply put, malicious actors have the upper hand and security-aware developers are sorely needed to serve as the front line of defense.

    Interactive challenges that focus on simulating such breaches move developers from passive recall, to applying skills that have an impact on the real boss fight: stopping attackers in their tracks.

  • Mattermost Offers DevOps Command Center in the Cloud

    Mattermost Offers DevOps Command Center in the Cloud

    Mattermost today launched Mattermost Cloud, a software-as-a-service (SaaS) platform for managing DevOps workflows using pre-built playbooks that comes integrated with a wide variety of third-party developer tools.

    Chandar Venkataraman, executive vice president and chief product officer for Mattermost, said Mattermost Cloud enables IT teams to take advantage of a single-tenant DevOps platform that they don’t have to maintain in a way that forces developers to give up their preferred tools.

    In contrast, other DevOps platforms that are managed as a service require developers to make use of a narrow range of tools provided by the platform vendor, he said.

    Built on top of an instance of Kubernetes, the single-tenant capability also ensures that any data or artifacts stored on the platform remain private. The Mattermost Cloud Professional edition, available today, provides a full set of collaboration and DevOps features, while the Mattermost Cloud Enterprise edition, currently in beta, adds dedicated single-tenant cloud infrastructure, enterprise-grade secure network topology and strict data residency options.

    By building the platform on Kubernetes, he noted, it becomes much easier to scale the Mattermost Cloud platform up and down as required.

    Mattermost Cloud is essentially a DevOps command center that provides single pane-of-glass pre-built workflows that address most common DevOps processes. IT teams can add their own custom workflows as their DevOps processes mature, Venkataraman said, noting plugins for Jira, Opsgenie, PagerDuty, GitLab, GitHub and Jenkins are already available.

    The cloud platform also includes a pre-built best-practices incident management playbook to enable DevOps teams to address issues as they arise rather than trying to resolve them using a legacy ticket-based approach to IT service management (ITSM), he added.

    Venkataraman noted Mattermost doesn’t expect DevOps processes to supplant existing ITSM platforms based on ITIL-frameworks. However, many DevOps teams are looking for ways to resolve incidents within their existing workflows using, for example, a messaging platform versus a workflow designed for IT support staff.

    In general, Venkataraman said, many organizations that are relatively new to DevOps don’t want to manage the underlying platform. At the same time, he noted there are also many IT organizations that want to allocate more resources to writing code versus managing a DevOps platform.

    Each IT organization will need to decide when it makes sense to stand up their own platform for managing DevOps workflows and playbooks instead of building and maintaining their own control plane. Many of those IT teams are already making use of artifact repositories and continuous integration/continuous delivery (CI/CD) platforms that are accessed via the cloud, so a DevOps command center is only one more logical extension.

    Just as importantly, isolating the DevOps command center from the rest of the underlying DevOps platforms ultimately makes it easier for IT teams to switch out tools and platforms over time as they best see fit. The challenge now may be in finding a way to decouple workflows that are deeply intertwined with a specific platform.

  • CircleCI Report Finds DevOps Teams Adjusting to New COVID-19 Normal

    CircleCI Report Finds DevOps Teams Adjusting to New COVID-19 Normal

    An annual State of Software Delivery report published today by CircleCI suggests that after a spike in developer activity last spring at the beginning of the COVID-19 pandemic, the pace at which code is moving through a continuous integration/continuous delivery (CI/CD) platform has returned to normal levels even as developers continue to work from home.

    CircleCI CEO Jim Rose said after any initial rush last spring, it appears maintaining that level of productivity is simply unsustainable for most organizations. If heroic measures are continuously required, Rose noted it’s only a matter of time before DevOps teams start to burn out.

    Based on an analysis of 55 million data points gathered from 160,000 projects spanning more than 44,000 organizations, the CircleCI report finds that despite the ability of a handful of organizations that can deploy code multiple times per day, most organizations on average run workflows less than once (0.7 times) per day.

    However, Rose noted, there is too much focus on the number of times per day code is being deployed. The more important metric is duration. Half of the 11 million workflows measured by CircleCI finished in less than four minutes. Three-quarters finished in less than 11 minutes, with 95% of all workflows measured finishing in less than 35 minutes.

    Rose said durations are longer than in previous years, which suggests more testing is being included in workflows. In an ideal world, Rose said workflow durations should be in the range of five to 10 minutes.

    The report also finds 50% of the workflows went from failing to being successfully deployed in 55 minutes on average, with the median success rate 61% of workflows. Splitting the workflows by the ones run on default branches versus the ones run on non-default provides more insight, and the median rates are 80% for the default branch and 58% for the non-default branch. Failure rates for the non-default branch are higher because that’s the branch most developers employ to experiment in a way that doesn’t impact the primary workflow.

    Rose said the report also suggests there is a correlation between larger team size and better overall engineering performance. In times of uncertainty, IT leaders should consider increasing the size of teams to reduce burnout and maximize flexibility. Depending on the scope of the project, Rose said the CircleCI data shows that somewhere between five and 20 code contributors is the optimal number of team members. IT organizations would also be well-advised to consider how those team members are geographically distributed to maximize the number of hours in a day any project is being worked on without having to overwhelm a small number of developers working in the same time zone.

    As has always been the case, DevOps success over the long term requires organizations to balance multiple factors and metrics. After all, the primary goal for most organizations is not so much to increase the amount of code being deployed as much as it is to increase the quality of the code that ultimately gets deployed in a production environment.