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.
Awareness and adoption of DevOps continues to grow. A 2016 DevOps trends report found that DevOps adoption increased from 66 percent in 2015 to 74 percent in 2016
In 2016, visitors to the SEI DevOps Blog were drawn to posts highlighting successful DevOps implementations at Amazon and Netflix, as well as tutorials on Fabric, Ansible, andDocker. This post presents in descending order (with number one at the bottom being the most popular) the five most popular DevOps posts in 2016.
The term "software security" often evokes negative feelings among software developers because it is associated with additional programming effort, uncertainty, and road blocks on fast development and release cycle. To secure software, developers must follow numerous guidelines that, while intended to satisfy some regulation or other, can be very restrictive and hard to understand. As a result, a lot of fear, uncertainty, and doubt can surround software security. This blog post, the first in a series, is based on a keynote I recently delivered at the International Conference on Availability, Reliability, and Security (ARES). In this talk I describe how the SecureDevOps movement attempts to combat the toxic environment surrounding software security by shifting the paradigm from following rules and guidelines to creatively determining solutions for tough security problems.
So, you're using Vagrant, and maybe you've even read my earlier post on it, but your Vagrant box doesn't have everything you need. Or maybe it has too much, and you need something simpler. For instance, do you find yourself installing or removing packages or fixing packages to specific versions to get parity with your production platform? Or maybe you need more extensive auditing over your environment, such as when you (or your customer) can't trust a third-party box vendor. Or you need a way to clone a virtual machine for parity with the production environment. What are your options? In this blog post, I will explain what a box file is and how you can have more control over your Vagrant workflow by creating your own box. I will also introduce Packer as a tool to create a Vagrant box, and I will finish with an example for managing Vagrant box versions and distributing updates in a team setting.
Systems engineers working today face many challenges, both in building the complex systems of systems of the future and in building the complex systems of which they are composed. Systems engineers need to be able to design around stable requirements...