According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.
Data analysis is complex and, at times, overwhelming. Automation increases an analysis team's ability to continuously improve their process. Specifically, the automation of software is the best way to manage all of the iteration and repetition that proper data analysis requires. DevOps is the perfect fit when planning a project that requires software, automation, and collaboration. In particular, DevOps improves all aspects of the data analysis process and allows teams to automate all software-based aspects of the data analysis process and effectively collaborate with all project stakeholders. In this blog post, I explore the ways in which DevOps improves data analysis.
When it comes to information technology services that are customer facing, traditional enterprise organizations tend to favor stability over change. According to a Netcraft survey from March of last year, there were 185 million web sites hosted by Windows 2003, an operating system that has been out of support since July 2015 . Many of these servers are still running because of the "if it isn't broken, don't fix it" motto. While reducing software and system churn would seem like the best way to promote stability, it can eventually harm application security and stability. This blog post explores some basic DevOps practices that will improve application security while helping to maintain a stable operating environment.
Data collection and storage are a large component of almost all software projects. Even though most software projects include a data component, this topic is rarely discussed in the DevOps community. The adoption rate of database continuous delivery (CD) is about half the rate of application CD. There are several reasons for this, but the primary one is that databases rarely change as often as applications do. There may be a few model changes, but generally there are no major architectural changes that occur in relation to the database level of your software. Many DevOps practitioners thus do not spend the time to provide continuous delivery of their data storage solutions, which became very apparent when our team was recently tasked to solve a complex problem. In this blog post, I will explore the application of DevOps principles to a data science project.
In the first six months of 2017, an increasing number of blog visitors were drawn to posts highlighting topics such as secure Devops, successful DevOps implementations at Amazon and Netflix as well as tutorials on using DevOps technologies such as Fabric or Ansible. This post presents the 10 most popular DevOps posts in the first six months of 2017.
You've heard the hype and read dozens of blog posts on DevOps, and your organization has decided to make this cultural shift in hopes of taking advantage of automation and the benefits of the Agile methodologies. Making this shift as an engineering team, however, can often be cumbersome because many tech professionals are still unfamiliar with the technologies required to implement a complete DevOps pipeline, let alone one that includes security automation as well. In this blog post, I will introduce Microcosm, a miniature, secure DevOps pipeline we developed at the SEI that is available through infrastructure as code. Microcosm represents a miniature version of a secure DevOps pipeline in comparison to what would actually be found in a large, enterprise environment.
When implementing DevOps, experts typically focus on process and tooling, but little emphasis is given to the psychological and social aspects of team members, which can pose encumbrances to DevOps adoption in production software houses. Training development staff on DevOps tools and processes is costly, so a significant risk occurs when training fails to produce full adoption by development teams. At the end of the day, people will adopt the tools and processes, but if there is no heathy culture, then DevOps fails to help the organization, and eventually may even cause more harm. In this blog post, I explore strategies for understanding and overcoming employee resistance to DevOps.
My prior blog post on product lines in DoD sustainment described the complexity of contractual relationships in a DoD software product line. Recall that a software product line is a collection of related products with shared software artifacts and engineering...