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.
From the dawn of humanity, people have been trying to represent knowledge visually to communicate ideas to their peers. Yet we still struggle to this day whenever we need to present information in a way that is both simple and effective. In this blog post, the first in a series on Information Visualization in DevOps, I explore how visual graphics can assist in the DevOps process.
We often discuss how important it is to incorporate security into all parts of the DevOpssoftware development lifecycle (SDLC). For example, my post Security...Security Everywhere discusses what types of security can be incorporated into the different phases of the SDLC. However, incorporating security is often hard, due to part to the fact that most automated security testing tools are only available in a couple of places in the SDLC, primarily the continuous integration (CI) server. There is an opportunity for lots of testing without much additional overhead. This opportunity presents itself when developers push their code to a central code repository, specifically git repositories. Using git hooks, developers can write tests for their code and run them when code is committed and pushed to the repository. These tests will actually prevent developers from committing and pushing their code if they contain security flaws. In this blog post, I will introduce and present a demonstration of Overcommit, an open-source tool that manages git hooks.
Software development project stakeholders can often be tempted to put security requirements on the back burner when developing software systems. During one particular large-scale software development project I was involved with, which was a distributed system consisting of many components communicating over the network, runtime performance was the most important quality attribute. The engineers brilliantly invented their own lightweight protocol to maximize runtime performance. Once the system was to be transitioned into production operations, it was discovered that encryption and authentication had to be added to comply with the security requirements of the customer's site. These changes resulted in degraded runtime performance and delayed the system's ability to be used in the field. The project went over schedule, and costly rework had to be performed to accommodate the added overhead of secure communications. In this blog post, I will explore rethinking software requirements to maximize security and minimize risk.
According to an FBI report on workplace violence, 80 percent of the active-shooter situations that happened in the United States between 2000 and 2013 took place at work. Of those active-shooter incidents cited in the report, more than 46 percent were perpetrated by employees or former employees and 11 percent involved employees who had been terminated that day. The CERT Insider Threat Center conducted two back-to-back research initiatives to gain a deeper understanding of incidents of workplace violence in the context of insider threat. In this blog post, I describe our most recent research initiative to explore the technical detection of intended harm to self and/or others.