devopsy.kinsta.cloud

Tag: security testing

How to Create Bug-Free Blockchain Apps
While all developers strive for bug-free code, it’s particularly crucial in a blockchain deployment where sensitive data or other confidential info is being exchanged, such as in health care or finance. However, some businesses have learned that lesson the hard way. Cryptocurrency exchange Binance recently revealed a devastating security breach that resulted in a loss of more than $40 million. While this is a large sum, a security breach could be even more costly for businesses that lose private messages, confidential contracts and more.

Rebuilding (and regaining customer trust) is not where organizations should be spending their time. A better way forward is for company leadership to mandate a blockchain test automation strategy from the very beginning.

While most software testers are familiar with testing web applications, they may not be sure how to approach blockchain testing. The good news is, some of the same focus areas of web testing apply to blockchain testing, too (functional, performance and security). However, blockchain involves a greater number of tests, effort and focus areas, such as infrastructure orchestration, staging and simulating scenarios in a distributed environment, which requires an even greater level of expertise.

Because of these additions, fixing a bug in a blockchain app requires several extra steps and, as a result, it is more time-consuming and costly than fixing bugs in other apps. For example, to reproduce bugs or verify code, developers should perform these steps multiple times:
1. Form a new endpoint.
2. Deploy new code to the new endpoint.
3. Migrate the current data to the new back end.
4. Suspend the old back end.
5. Update all front ends to the current version.
After that, verifying the bug-fix performed by testers or continuous integration (CI) tools will require these steps again. This complexity makes it difficult to release bug-free blockchain applications, yet doing so puts organizations and their customers at risk of financial harm. Due to the high-risk nature of deploying blockchain applications, it’s critical that testing is included in the managerial vision and strategy.

To release blockchain apps with bug-free code, businesses should follow these guidelines:

Integrate Test Automation Into Your Blockchain Testing Strategy

Test automation can relieve testers from performing thousands of orchestrating tests manually, which is both difficult and inefficient. A good system architecture should be scalable, maintainable and testable, so teams can test components independently along with mocked components. If a test requires a different environment or infrastructure, infrastructure as code (IaC, such as Puppet, Chef, Ansible and AWS is invaluable in setting up appropriate test environments. Another crucial part of the strategy is to provide the infrastructure with declarative definitions and allow developers to implement codes that support test automation.

Run Unit and Integration Tests to Cover Both Back End and Front End Code

Blockchain applications contain at least a back end (a set of smart contracts or chain codes running on a blockchain) and a front end (where users can interact with data stored in the blockchain). Performing unit tests will cover both back end and front end code, and, because of its critical role to blockchain apps, its primary focus should be on the chain codes. Integration testing, however, should cover the various types of oracles and front end applications. Performing additional tests will eliminate any holes that can threaten the back end by verifying the integration between the UI and chain codes.

Perform Tests in a Local Infrastructure

Though public blockchains (such as Bitcoin or Ethereum) have several test-nets, it’s optimal to perform the tests in a local infrastructure. Local infrastructures are lightweight, faster and more stable for unit and integration tests. For example, in a Ganache local infrastructure, it’s possible to run more than 1,000 unit tests on five Ethereum smart contracts with approximately 3,000 deployments in an hour or less.

Continuously Update Security System Test Suites

Blockchain is a multi-party infrastructure and in some cases, it is a public network. As a result, these applications will be visible to many stakeholders and may even be open-sourced to the world. This level of transparency means that hackers are able to study the programs and plan attacks based on a particular system. Continuously updating security system test suites will ensure applications are protected against all common security vulnerabilities.

Minimize Continuous Testing Pipelines for Each Phase of the Development Process

Layering integration and unit tests in a local infrastructure with continuous updates to the security system test suites creates a continuous testing pipeline that is essential to high-quality blockchain code. Continuously verifying code changes in multiple environments, such as local blockchain and test-net, ensures high-quality code is delivered to the production blockchain. These tests, however, can last hours or days for each code change, so it’s important for teams to minimize and create lean pipelines that focus on test stages, test types and test environments, and develop multiple pipelines for code at each phase of the development process.

Build Customized Tests Suites to Eliminate Prospective Cheating Holes

Test teams also need to customize test suites in the pipelines to cover both functional and security testing. Covering security cases is important, but unit test modules should also exercise smart-contract-unit potential security threats, such as overflow and re-entrancy, to eliminate as many prospective cheating holes as possible.

Due to the nature of decentralization and orchestration of underlying infrastructure, developing bug-free code for blockchain applications presents many more challenges than other applications. By taking best practices from traditional software testing, especially test automation, and customizing them for blockchain development, businesses can achieve bug-free blockchain coding and protect their most vulnerable applications.

— Thong Nguyen
May 31, 2019
Security Testing: Reducing Resistance to Change in an Agile and DevOps World

Software development has evolved, but security testing has not. That has to change

In the bad, old days—which, sadly, many are still living in—security testing was tacked onto the end of the development process. Security testing hasn’t been a feature of software engineering for around 15 years now, since agile supplanted waterfall as the primary development methodology. The old idea of security testing as an independent, external audit, where security folks sit far outside the development process, is ineffective at preventing massive data breaches and ensuring developers have the knowledge required to build secure applications.

Until the mid-1970s, the concept of desk-checking software was necessary due to the slow turnaround time of punch cards, compilation and batch job testing. Desk-checking and formal verification are the genesis of the security audit. Though software engineering has developed through timesharing, real-time debugging, individual computers for each developer, waterfall, object-oriented programming, rapid application development and, finally, agile and DevOps, security is still stuck in the mid-1970s. Security professionals are not auditors and security audits are not a viable replacement for sound security engineering.

There is no doubting the need for objective tests along the way, but the construction industry shows us the way here. Any large building project regularly tests random concrete deliveries for compression and tensile strength. While every metaphor breaks down if you push it too far, there is a place for continuous security testing in an agile world. This should take the form of executable tests, rather than reports.

Modern “unicorn” development is proud of the DevOps culture that allows developers to push code into production many times a day. But in the DevOps deployment model, it’s impossible for traditional security practices to keep up. A typical security testing schedule is every 12 to 18 months if you’re lucky, or never if the app is not considered significant. There could be thousands of untested builds in that time.

How do we fix this? How do we scale? The security profession must adopt agile and DevOps processes and use the same tools as developers. It is that simple. However, it’s incredibly difficult for many. Historically, security professionals haven’t come from a development background, and so the concept of delivering security tests as source code is at odds with 40 years of penetration testing.

The first thing that must change is the way organizations receive results. One of the tenets of an early agile methodology called “extreme programming” (XP) is “you ain’t gonna need it” (YAGNI). I posit you “ain’t gonna need” a PDF report. Results should be delivered via APIs, directly into existing development defect trackers, such as Jira or GitHub Issues, or a vulnerability management solution. The worst possible outcome is a 60-page PDF sitting unread in someone’s inbox—or worse, trying to scrape it or manually cut and paste into an Excel spreadsheet. Developers will never see the entire report, as if it is a state secret, and yet they have to fix discovered issues.

I hear screams in the distance! How’s an internal audit going to verify that security is in place and effective without a PDF report? They can and should look at the results of builds. It is that simple. If developers can demonstrate that every build for the last 12 months passed security unit and security tests, that is a job well-done. No one asks accountants to provide a PDF report of the latest reconciliation as proof that reconciliation is working. The evidence is that the numbers are the same in the online accounting and banking systems. If an auditor wants to produce a cover sheet saying that they randomly sampled build testing results over the last 12 months and assert that the results are a true and correct representation of security effectiveness, good for them.

Security professionals are not auditors and should not be writing reports. They should be testing software, sharing knowledge and writing tests. Security professionals should be embedded with developers, helping them understand why a security test has failed and discussing solutions, possibly even coding a potential solution. Security professionals can learn about the enterprise and specific application business risks, and the development team can learn how to fix current issues and protect against security failures in the future.

It’s critical to understand that as executives ponder this change, there will be resistance. The security industry is structured around delivering short-duration, high-skill testing. This type of testing often tests the skill of the assessor and web application firewalls, and not the application itself. Modern security practices—such as the one I lead—have moved to abuse cases, where no web application firewall will protect you. We have offerings and talk with our clients about agile CI/CD pipeline security, but even though what we want to move on to will be utterly obvious to everyone in a year or two, resistance is strong.

How do you move forward in the interim? Ask your security vendors to deliver proof-of-concept unit or integration security test cases to be run in the build pipeline. Provide source code to your apps so they can write the tests in the same codebase to test every build and allow your developers to maintain these tests.

In the meantime, review the effectiveness of your PDF-based security program. Challenge your vendors to come up with something that works with your development teams rather than treating them as adversaries.

— Andrew van der Stock

February 20, 2019
CA Technologies Extends DevOps Push

At its CA World 2017 conference this week, CA Technologies moved to tighten the integration between the various elements of its DevOps portfolio acquired over the last year and unveiled CA Digital Experience Insights, an analytics-infused monitoring tool delivered via a software-as-a-service (SaaS) model.

The company also announced an instance of the CA Microservices Gateway that allows the API management platform to be deployed as a Docker container. Earlier this week, CA Technologies launched a beta release of Fastrack.io, a service for monitoring Kubernetes clusters based on machine learning algorithms and embedded in an instance of the open-source Prometheus container monitoring service.

The company is also adding CA Virtual Test Data Manager, a tool that makes it simpler to create copies of large data sets for testing purposes, and CA Service Virtualization Community Edition and CodeSV, a plug-in that enables DevOps teams to invoke service virtualization from within their integrated development environment to mimic external services without having to connect to an actual instance of those services running in a production environment.

Additionally, CA Technologies announced it has integrated CA Veracode security testing software with CA Automic IT automation platform, and announced general availability of BlazeMeter API Test, a SaaS-based API testing tool, and CA Continuous Delivery Director SaaS, a service that integrates the DevOps toolchain.

Aruna Ravichandran, vice president of DevOps product and solutions marketing for CA Technologies, says each of these offerings are part of a larger company effort designed to enable organizations to set up their own software factories. Now that more organizations have come to realize their ability to differentiate themselves depends on custom software, many of them want to be able to acquire all the integrated DevOps tools required to achieve that goal from a single vendor, Ravichandran says.

CA Technologies is making a concerted effort to link the need to create a software factory as a prerequisite for driving digital business transformation at scale. To achieve that goal, she says, control over IT operations is continuing to shift to the left as developers become more accountable for the entire application experience. Offerings such as CA Digital Experience Insights make it simpler for developers to holistically manage those end user experiences by infusing predictive analytics and machine learning algorithms coupled with improved data acquisition techniques in a single service, Ravichandran says.

CA Technologies clearly wants to become a DevOps force to be reckoned with. In the last two years it has acquired Blazemeter, Automic, Veracode and Runscope. Prior to that, the company acquired Rally Software, Nolio, Grid Tools and Layer 7 Technologies. From here it’s likely CA Technologies will continue to expand its portfolio by acquiring companies while tightening the integration between the various code bases that make up its DevOps portfolio.

The company’s stated goal is to provide a suite of DevOps tools and services that are too compelling to ignore without forcing IT organizations to consume a product or service they don’t want by maintaining open interfaces across the portfolio. The degree to which CA Technologies can succeed in that effort remains to be seen. But there’s no getting away from the fact that the company has now assembled a formidable DevOps arsenal of products and services.

— Mike Vizard

November 17, 2017
What Happens to Test in a DevOps World?
I am always surprised by the urban legends around DevOps. One of my favorites is, If you implement a DevOps methodology, you can stop doing test. People famously quote that Netflix only tests in production as evidence of this. This is perhaps more like of game of Telephone, where much of the story gets lost in translation. It is true that Netflix created a tool called “Chaos Monkey” which generates failures in production as a way to test the fault tolerance of its software in large-scale production use. However, this is not Netflix’s only test; it is an additional type of testing at scale that allows the company to test in new and different ways. Netflix still tests in software development.

Okay, now that we are past the notion that DevOps is about eliminating testing, let’s look at what really happens with test in the DevOps world. In fact, the goal is for testing to happen everywhere and all the time. Let’s look at the two directions test can shift: left or right.

Shift Left

DevOps methodology encourages automation of activities across the entire development process. This can be realized by automating the link between development and test. Often implemented with an automated build tool such as Jenkins, a set of automated tests are triggered whenever a developer completes a build of new code. Of course, this means that both development and testing processes must be automated. Once you reach this goal, then testing can happen all the time. Every time developers want to check in new code, they can trigger a small set of “smoke tests.” If those succeed, they can check in code and when the build happens, they can trigger a larger set of regression tests. The result is a left shift of testing into development.

Benefits of left-shifting test include:
- Move testers into scrum teams to work on stories together with developers.
- Design tests in parallel with development.
- Give developers and testers the flexibility to help each other to reduce bottlenecks.
- Early detection of bugs, shortening the critical metric for time between creating a bug and fixing it.
- Increased transparency of code dependency issues because they are raised during the nightly (or more often) regression testing.
- Virtual elimination of the test bottleneck that occurs after development is completed.
Shift Right

The urban legend about Netflix may be wrong, but that doesn’t mean that there isn’t merit to right-shifting test into production. Automated testing in production is effective for tests that would be impossible to perform outside of production, including scale testing and resiliency testing. Production is also a great place to introduce A/B testing by offering different interfaces to some customers and measuring the differences in business results.

Benefits of testing in production include:
- Better understanding of the real production environment and workloads.
- Early feedback from customers on new features and user experience.
- Better resiliency.
- Overall better user experience for customers.
No Shift

Wait, if we shift left and shift right, is there any testing left to be performed in test? There are still a range of tests that need to be performed by the test team. With full automation, these tests can be performed at a variety of times and don’t need to be a bottleneck to release. These tests include:
- Performance testing
- End-to-end use-case testing
- Security testing (don’t think about doing this in production!)
- Manual testing – often for user interface or mobile testing that is most difficult to automate
DevOps methodology is not promoting the end of testing, but in fact a widening of testing to encompass all of the steps in the DevOps cycle. You know what they say: Test early and often! And next time you are sitting around the campfire discussing urban legends, let’s leave Netflix out.

About the Author/Joan Wrabetz

Joan Wrabetz is the CTO for QualiSystems. Most recently, she was the VP and CTO for the Emerging Product Division of EMC. Joan received her MBA at the University of California, Berkley, and MSEE at Stanford, and a BSEE at Yale. She has held teaching positions at the University of St. Thomas, St. Mary’s University and the University of St. Thomas, St. Mary’s University. Joan holds patents in load balancing, distributed systems, and machine learning classification and analytics. Her experience inclues: founder and CEO of Aumni Data, CEO of Tricord Systems, Vice President and General Manager for SAN operations at StorageTek, Founder and CEO of Aggregate Computing, Management and senior technical positions at Control Data Corporation and SRI International, Partner with BlueStream Ventures.
June 13, 2016
Q&A: Quali’s Wrabetz on Security Testing
DevOps is the perfect storm of automated testing and development that should make secure software commonplace. Yet, there are hurdles to testing for security. devopsy.kinsta.cloud asked Joan Wrabetz, CTO of Quali, about security, DevOps and her laundry list of those testing challenges.

David Geer: Isn’t secure software important to DevOps?

Wrabetz: DevOps is a practice of continuously deploying applications into production clouds. In order to automate the deployment of applications into production, it would seem essential for security testing to be a part of that automated process. In fact, when talking with one financial services firm, they said that they don’t deploy continuously into production because they are concerned that to do so would break the law. They are required by law to ensure that applications comply with their regulatory and privacy requirements before they are deployed into production. The only way to do that is to perform security testing. Thus, in order to achieve continuous deployment, they would have to integrate security testing into their DevOps flow.

Geer: So, why isn’t security testing a core part of DevOps already?

Wrabetz: The reasons are both technical and organizational. Organizationally, security testing is usually handled separately from development or product release-oriented testing, often by a completely separate group. As a result, it is not necessarily associated with the application release process.

The technical reasons are related. Historically, security testing has involved reproducing the production infrastructure and network configuration as accurately as possible so that security vulnerabilities can be identified. Often, development and test teams working on DevOps do not invest in creating accurate reproductions of production infrastructure for their normal development and testing. So, they are not prepared to perform security testing as part of their normal DevOps flow.

Security testing at many financial services firms exemplifies both of these issues. These firms typically outsource their security testing to one of a number of service firms who perform that testing on their own networks or in the cloud. The outsourcing of the security testing process is a big inhibitor to incorporating security testing into a continuous and automated DevOps process. In addition, when we asked these financial services firms how well their outsourced security testing represents their real production information technology infrastructure, they really have no idea. Clearly, any testing that does not match the production environment is not helping to reduce the security risk that the organization faces.

Geer: What kinds of security testing do you feel is most relevant to DevOps?

Wrabetz: The type of security testing that is most relevant to the DevOps flow is application compliance testing. For this type of testing, new applications are inserted into a network that emulates the information technology production network as accurately as possible. Testing with load, traffic and disruptive events is performed to determine whether the new application or upgrade might open up a vulnerability in the production environment. That includes privacy and data protection regulations, security requirements and any other business compliance standards that the organization is subject to. This testing is performed before pushing any new upgrade or application into production to ensure that compliance requirements will be maintained.

Geer: What are some common problems with security testing as part of DevOps?

Wrabetz: There are some common problems that make this type of testing uniquely difficult as part of a DevOps process, and in many cases, much harder to perform than other hardware and software testing. For example:
- The tests must run in a configuration that exactly matches the current production configurations.
- Security tests are systemwide tests, not tests of a single piece of hardware or software.
- The tests must run with realistic traffic that simulates typical production traffic.
- Security testing must allow automation of setup, configuration and testing processes in order for it to be incorporated into a DevOps flow.
- Networks are large-scale and difficult to reproduce in a test.
Security Testing Critical

DevOps is in its infancy, but it won’t be forever. Now is the perfect time to surmount these obstacles, test for security and feed the results back into coding for security early and often.
May 26, 2016
Minimum Viable App Doesn’t Mean Minimum Security

It’s estimated that the total market for mobile apps will hit $143 billion this year. A big portion of that budget will be enterprise mobile app development. By next year 25 percent of enterprise IT budgets will be aimed at their mobile app efforts. Yet, despite these efforts, most enterprises are still falling behind in their mobile app development pipelines by 12, 15 and even 20 weeks.

To help clear that backlog and meet their internal mobile app demand, more enterprises are focusing on delivering the mobile apps with the features that hold promise to produce the most return on their efforts; that is, the apps that people likely will use and will do the most, for the least investment, to help to improve their daily work lives and productivity. Or, this minimum viable product (MVP) is the minimum required in an app to prove out its app concept.

But when moving apps out quickly, enterprises risk skimping in areas of quality and especially security, which can pose a risk to data that should be handled with care, notes Isaac Potoczny-Jones, research lead, Computer Security with security research and development firm Galois.

“There’s definitely a lot more development in mobile happening,” says Potoczny-Jones. “I think the [security] best practices in mobile aren’t as well-developed as best practices for the web. I think that’s getting a little bit better, and there’s a very fascinating challenge with security [with MVP] because security is a non-functional requirement.”

Of course, apps must be developed with good mobile security—including app password management, server side controls, cryptography and other best practices—in mind. The OWASP Top 10 Mobile Security Risks provides an excellent overview of common mobile risks and associated mitigations.

One of the challenges with mobile security testing is that the best practices and associated processes are not well understood by most, at least not yet, and quality mobile security testing tools are not deployed in many organizations. Plus, those organizations using some of the common mobile security testing tools find that they don’t always suffice and they often have to build their own automated toolsets.

The risk with fast-tracked MVP apps is that they never get anywhere near a security test before being shipped to production. But these apps—just like any other apps that get near enterprise data and networks or may access sensitive, confidential or regulated data—must be vetted, threat modeled and tested (static and dynamic app testing), along with the usual quality tests. And with MVPs, it’s just as important that this testing be an integrated part of the process from the beginning.

The best way to achieve this, of course, is through awareness and secure code training with developers.

Companies may want to consider creating an MVP development guide that could detail security considerations for the MVP. Such a guide could help developers determine what security best practices to follow, as well as what apps need to be sent to the security team for reviews—and when.

Potoczny-Jones says there’s no reason, except for maybe carelessness, why MVP apps are being built with minimum security considerations, as most lean development methodologies have security testing built into their processes. “Once you get these teams to include security testing being a part of [what they consider] ‘being done,’ which I don’t think a lot of people have, then they’re going to do the right things. You’re either going to start to build security either into the user stories or the acceptance testing,” he says.

That’s for sure, and it shouldn’t be left to the end of the development process. “You can’t leave it to just be at the end of the process. If you leave security testing toward the end, naturally your schedule is going to slip. You’ll find that there’s a lot more work to do. Then you’ll be in this unfortunate position of having to decide whether to fix things and let the schedule slip, or choose to let something go out the door that’s not secure,” Potoczny-Jones says.

February 10, 2016
Embedding security testing to avoid headline-inducing configuration fails

When news broke earlier this month about the nation’s largest bond insurer exposing sensitive account information to Google’s indexing spiders due to a server misconfiguration, many an IT professional wondered how such a massive fail could have been neglected for so long. Security experts called it out-and-out negligence by the company, MBIA. But the truth is that plenty of other businesses with traditional IT departments could have just as easily suffered the same fate. MBIA was just unlucky enough to have caught the eye of security researchers and inquiring journalists.

The fact of the matter is that most IT shops today still stink at configuration management. According to a survey out by Avaya earlier this year, 82 percent of organizations today still experience network downtime due to human error around configuration changes. In MBIA’s case, it wasn’t downtime but a data exposure that MBIA suffered as the result of a misconfigured Oracle Reports server tied to a web application. The issue allowed back-end data such as account numbers, routing numbers and other sensitive data to be indexed by Google, along with administrative credentials that would let attackers access any other data not already out there for the world to see. Avoiding these kind of blunders stands as one of the big value propositions of DevOps processes and the orchestration toolsets that support them.

“If they’d used DevOps, they’d probably have caught this issue much sooner,” says Rajat Bhargava, CEO of JumpCloud. “They should have controlled configs and change management, and DevOps is generally useful for those things. You make a change, you make it in code and theoretically people ought to be able to document these changes and then apply them across the board. So it is a little more controlled than someone going in manually and changing a setting and forgetting about documenting it.”

However, when it comes to reducing the overall risk posture of infrastructure managed by the constant flux of DevOps’ fast iterations, Bhargava believes many organizations could stand to take their practices to the next level. He says they can do that by better embedding security testing into the DevOps cycles.

“Clearly, DevOps shops are already doing automated testing around their code,” he says. “So there’s no reason why we can’t embed automated security testing just as we’ve automated QA and so on.”

This means not only testing the security of the code itself, but also of the configurations and overall system security once that code goes live. Doing so acts as a backstop to the already automated configuration management process, which can be huge since a human error at the top of the orchestration stack could prove even more disastrous than the kind of one-off configuration error that hurt MBIA.

“With great orchestration and configuration management tools, comes great responsibility. A simple misconfiguration of a system is only going to be compounded to the nth degree when you introduce DevOps configuration tools,” says Andrew Storms, a security and DevOps expert.

Just as DevOps can speed up update cycles for software and configuration, adding security automation and testing into the equation can speed up response to problems—whether they come from internal human error or news of new threats that need immediate attention from both dev and ops teams.

“For example, I know of companies that patched their entire DevOps enterprise for Heartbleed in a few hours,” Storms says. “Security best practices dictate that the security of systems be continuously checked in all environments — from early in the development process all the way into the production environment. Security is struggling to retool their processes and mold their staff to fit into the new ever changing DevOps world. It’s not just DevOps shops that need to do a better job at incorporating security into their processes. However, combining DevOps automation tools with security products is a true force multiplier that is our next best hope to get security right.”

Rich Mogull, CEO for analyst firm Securosis, agrees. He sees the kind of embedded security testing that Bhargava is advocating for as a huge opportunity for DevOps organizations.

“If you’re using the DevOps pipeline, to be able to go ahead and add security testing to that is a massive opportunity, and there are a bunch of tools out there to do some awesome testing (whose effect) would be extremely difficult to replicate using non-DevOps, traditional deployment testing,” Mogull says. “Not only is there an opportunity to get security engaged with automated testing, but you combine that with the building of a secure DevOps pipeline and I think we can wipe out entire categories of security issues.”
For example, at Black Hat Europe this week, Mogull says he talked to a company that no longer has to deal with the traditional firefighting exercise of patching machines.

“When they have to patch for something they actually just push the updated instances through their automation,” Mogull says. “So they’ll rebuild a new image and when they’re done with that, Jenkins will push it out into production and terminate the old instances.”

Mogull also believes that security testing of code is a big part of the value proposition of embedding security into DevOps. Security vendors like Veracode are now starting to tie into Jenkins to let developers know code has security issues and where to find those issues before pushing them into production. And tools like Gauntlt are making it possible to spin up cloud environments and automate vulnerability assessment, network scans and configurations and flag policies through a Jenkins plug-in. Additionally, in the same vein as the patching example, incident response to viruses can be completely rethought, because “if an instance gets infected or something along those lines, they blow them away,” Mogull says.

On a different security front, Mogull says the early adopter he spoke with at the conference also disabled SSH for admin log-ins to their production systems.

“Because, with DevOps, nobody should ever log into a production system,” Mogull says. “Any changes you make, you make at the beginning of your pipeline and then that gets pushed out and flows into production.”

October 20, 2014