devopsy.kinsta.cloud

Tag: code

Securing Third-Party and Open Source Code Components: A Primer
The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

Sacrificing Security for Ease of Use

While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

Where Does Responsibility Lie?

One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:
- Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
- Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
- Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.
While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

— Pete Chestna
May 24, 2018
Open Source: Is Your DevOps Org Vulnerable to an Equifax-Style Hack?

More than half of the Fortune 100 could be at risk of falling prey to the same kind of hack that caused devastation at Equifax last year, and it all comes down to poor open source component governance.

A new report out from Fortune reports that in the year after Apache Software Foundation issued an update to its Apache Struts framework to fix a well-known and critical deserialization vulnerability, more than 10,000 organizations downloaded the vulnerable version instead. Among those were 57 percent of the Fortune 100, according to numbers provided to Fortune by Sonatype.

The vulnerability is best known to have triggered the catastrophic breach at Equifax in 2017 that exposed the records of 148 million people. It’s a doozy of a flaw—a command injection vulnerability that allows for unauthenticated remote code execution—the kind of opening that gives attackers to gain a powerful foothold in affected systems.

“Seven months should be enough time for organizations to install the necessary patches and it’s unfortunate that so many still choose to download the older vulnerable versions,” said Nick Bilogorskiy. “There is really no excuse for this.”

This news should be sobering to DevOps organizations. Increasingly, they’re turning to an assembly-focused mode of software delivery that relies heavily on open source components rather than developers reinventing the wheel with new code. It offers a wake-up call for DevOps organizations to get serious about tracking and securing the third-party code they use.

In a recent DevSecOps survey conducted by 451 Research on behalf of Synopsys, 40 percent of organizations don’t perform any kind of software composition analysis on their software. That’s problematic, because it means that organizations often don’t know when vulnerable open source components such as Apache Struts are woven into their code base.

More disconcertingly, even fewer organizations have systems in place that can actually control when, where and what open source components are used within their software development. According to a different DevSecOps survey conducted by Sonatype, 62 percent of organizations don’t have any meaningful controls over which components are in their applications.

It’s a disconcerting statistic, considering the sheer volume of open source component use in development today—whether in DevOps shops or not. In a talk titled, “We are ALL Equifax” at the DevOps Connect event held at RSA conference last month, Derek Weeks highlighted the fact that open source component download requests have increased 87 times in the last 10 years.

“The growth rate and consumption volume is massive. And it’s coming into your organization,” Weeks told the audience. “And as a result of this behavior the applications your developers are building are now 80 percent to 90 percent open source components—built from code you did not write from scratch.”

Sonatype’s survey shows that almost 1 in 3 organizations this year suspect or have verified that they’ve suffered from a breach related to open source components in the last 12 years.

— Ericka Chickowski

May 11, 2018
Scrutiny of the Bug Bounty

Tips on building an internal bug bounty program

As a programmer, have you ever felt pressured to ship a release with lots of new features, while you knew that there was still a technical debt stability improvements and bug fixes that you wanted to address but didn’t have the time or scope to address? This happens all the time, along with the worry that a bug could cause problems for users leading to churn, revenue and reputation costs. Even the best software faces this challenge, balancing road map velocity with software stability, with each release. These imperfections can delay new software and feature releases at a time in which speed has become a powerful competitive advantage.

Developers and their organizations are challenged to bring products to market faster without impacting their stability and reliability. To be successful in this regard, organizations need a culture and resources to detect instability at multiple inspection points.

Enter the Bug Bounty

Of course, development teams are responsible for the quality and stability of the products they build. But those products often act differently in distinct environments. This problem isn’t new. Developers have always faced unknown issues prior to a release. However, dealing with such problems can be improved by considering the cultural solutions and tools used to reduce the bugs and increase stability.

Many organizations are creating internal bug bounty programs to promote security and application stability by reducing software bugs. These organizations promote a proactive culture of ownership and empowerment through internal programs that allow a variety of employees to assume the role of bug hunters. If the proper tools are available, bug detection responsibilities can be shared by development teams, operations and executive management.

Bug bounty programs enable teams to harness problem-solving skills to reduce bugs in application and software releases. Detection tools enable multiple teams to track and prioritize bugs that have the greatest business. This involves multiple teams and viewpoints in tracking and fixing bugs to prompt a variety of strong ideas and solutions.

A companywide bug bounty program can also promote awareness by involving participants outside the development process in a fun and challenging way. It creates an opportunity for people throughout the organization to improve product quality. It’s a good way to promote application stability awareness while encouraging employees to explore applications and software development.

Internal teams of engineers and developers are inherently well-suited for these types of projects because they know the infrastructure better than anyone, including its strengths and the weaknesses. By codifying the internal search for bugs, organizations can learn from mistakes and strengthen products while building intellectual capital. An internal program has the added benefit of identifying vulnerabilities before customers or users experience them.

How to Begin

To launch a successful program, consider the nature of the program along with the process and workflow for prioritizing where to allocate team resources. Specifically, an organization must define the business objectives that determine the kind of program you want to run, what the rewards will be and the scope of what will be tested. And with that information, determine the culture and tools that make it all possible.

It’s important to keep in mind that the two pieces (culture and tools) are not exclusive and don’t have to come in a certain order. You can use the right tools to build the culture, or you can create the right culture and right tools help codify and amplify that culture.

Considerations for a Successful Internal Bug Bounty Program

Business Objectives

What are the business goals and objectives that determine how the program is administered and what solutions will be used to achieve your desired outcomes?

Rewards

To attract the talent and attention needed to run a successful program, setting the rewards in line with your business objectives is an important step.

Scope

Detailing the scope of the program is essential to specify what the program intends to investigate, where to explore and what measures are allowed.

The more detail that can be supplied the better.

What Participants Need to Know

Internal teams need to know what they are signing up for when they choose to participate in the program and how anything they uncover will be utilized. Be clear for all involved, both the organization and the program participants.

It is crucial to point participants in the right direction and establish boundaries around where activities are expected and allowed and where they will be most beneficial. One tactic may be to keep a running list or dialogue detailing important targets. These targets will likely be a mix of web, mobile, IoT and API and can be prioritized in running lists.

Once acceptable targets are established, the best way to achieve a lasting impact is to have the tools in place that allow teams to build better software. Through culture and tools, it’s important for teams to be empowered to capture errors and diagnostic data in any app, prioritize the errors that have the greatest business impact, reproduce and offer fixes for the errors, all in clear metrics that multiple teams can understand and put to use.

Finally, ground rules are needed. This step will vary among organizations based on objectives and scope. But programs should detail how tests can be carried out, who specifically is authorized conduct them and how adjustments will be communicated as the program evolves.

Businesses may find many reasons for implementing an internal bug bounty program ranging from security to quality and even professional development. Whatever the reason, take the time to define the program clearly to keep it within the scope of your goals and pay close attention to the culture you promote and the tools that are implemented to be sure the program can achieve maximum results.

— Chuck Dubuque

May 10, 2018
Why NoSQL is the New Database Darling of DevOps

If developers are from Mars and testers are from Venus, your database administrator is stuck in Saturn. By nature, the database—and specifically the data it carries—has to remain stable even as the application code on top of it is changing faster than Donald Trump’s staff.

When it comes to the speed of your release cycle, issues with your database are like potholes. You don’t see them up ahead, and you only feel the pain after the damage is already done. The least flexible layer in an application is its database, rendering it the weakest link in any agile development process.

Get Your Database Up to Speed

The right NoSQL database offers the following features that can speed up your release cycle without falling into a pothole.

It’s Schema-less: When you make a new build, or issue a new release, your code will change. Obviously, it will go through QA and check out. However, just because it’s working doesn’t mean it’s working correctly. You may have changed the types of data your application is accepting. You may have changed the way your app works with data. Your schema is the blueprint for how you accept data. For a relational database, you need one. The more complicated the schema, the harder it is to change.

A NoSQL document database is schema-less, offering you the ultimate flexibility and speed in how to rearrange the way you handle your application’s data.

Rapid Scalability: The moment your application is a success, expect greater load. Greater load requires more hardware to handle that load while maintaining peak performance. A relational database demands you scale up, investing large amounts in a new server. NoSQL solutions let you scale out, creating data clusters on commodity hardware.

NoSQL lets you add new nodes to your database topography in minutes, expanding your ability to process requests from users at optimum performance.

Immediate Adaptability: New code doesn’t only change the type of data you are working with; it also can change how you work with the data itself. New queries mean whenever a user clicks a button, your database will have to relearn how to sort your data to answer new requests for specific items or aggregated totals.

A relational database will join tables and scour the data row by row to get your users what they want. If the whole thing changes, the process starts from square one. A good NoSQL solution uses dynamic indexing. It means that it won’t perform a query until after it finds the right index. It will either use a pre-existing index, improve on one or create one from scratch that will be made available for future queries.

Such a system reduces the performance hiccup by releasing new code in that the more you use it, the better indexes are created to maximize the performance of the database. Your Agile DevOps team can release new builds every day and the database will be able to keep up.

Platform testing: Agile without testing is like a lunchbox without the apple. It may not be the most appealing part of the meal, but you gotta have it. The right database lets you make queries in test mode without touching the disk itself. The data in real-time is separated from what you are testing.

Due to its inherent flexibility, a NoSQL database lets you re-create whatever test scenarios you need and measure function and performance to see how every layer is working under the new changes. You can also do this fast, keeping your development process moving right until the end.

Technical support that doesn’t hold you back: One of the biggest pitfalls in Agile is when you hand the fate of your next release over to people who have no idea how urgent it is that you get the issue resolved now. Bad tech support can take an issue that shouldn’t slow you down and freeze you up for hours, even days.

The right NoSQL solution offers tech support with quick response time, and engineers who have experience developing the database itself. It is important that they know how the database works, and can do better by you than reciting a series of standard test scripts.

Databases can also notify you of underperformance or any indications that there are escalating problems that need immediate attention before they become full-fledged issues. Small features such as these save you time in having to resort to tech support in the first place.

Conclusion

There are always risks involved with making changes to your application. The risk databases pose is that some changes can shut down your database and paralyze your application. A NoSQL solution can reduce this risk, and even speed up areas of your DevOps process.

— David Ben Horin

April 19, 2018
Study Traces Cybersecurity Issues to Lack of App Supervision

A global survey of 400 application developers conducted by Vanson Bourne on behalf of Veracode, a unit of CA Technologies that provides software development lifecycle tools, shines a light on how big an issue cybersecurity has become because of organizations failing to update components. The survey finds only 52 percent of developers using commercial or open source components in their applications update those components when a new security vulnerability is announced.

Pete Chestna, director of developer engagement for the Veracode, says the root cause of the many cybersecurity issues is that developers routinely incorporate libraries into their applications. But, after completing that task, there is no bill of materials that enables development teams or cybersecurity professionals to keep track of when those libraries need to be updated and for what reason. Without that bill of materials, it’s easy to miss a critical update addressing a newly discovered cybersecurity vulnerability, Chestna says.

The survey finds 83 percent of developers are using commercial and/or open source components, with an average of 73 components being used per application. But only 23 percent test for vulnerabilities in components as they are updated, even though there are an average of 71 vulnerabilities per application built using third-party components. Furthermore, the survey finds only 53 percent of organizations keep an inventory of all components in their applications.

The reasons organizations rely so much on open source and commercial software versus writing their own code span everything from best practices (53 percent) and an ability to work faster (51 percent) to being able to access advanced capabilities (47 percent) and company policy (47 percent). Whatever the reason, it’s apparent that more applications are being assembled rather than being developed completely from the ground up.

The top factors considered when selecting modules to be included in an application include functionality (62 percent), performance (48 percent) cost (44 percent), known security vulnerabilities (42 percent) and reliability (40 percent).

Unfortunately, there’s not much in the way of DevSecOps processes spanning the development process. This report shows that development (44 percent) or security (31 percent) teams are most likely to be responsible for the maintenance of third-party commercial and open source components. But the number of organizations that enable developers and cybersecurity teams to work together remains relatively small. A quarter admit (25 percent) admit they don’t even have a formal application security (AppSec) program in place.

On the plus side, more organizations (41 percent) say they are likely to choose DevOps as their IT methodology, which, longer term, should put them in a better position to embrace DevSecOps.

When it comes to open source software, Chestna says that IT organizations would do well to remember that free software is much more akin to a free puppy versus say a traditional gift. Puppies require ongoing food and maintenance that comes at a cost to the owner. When IT organizations elect to employ open source software, they are assuming a set of responsibilities that many of them still don’t fully appreciate, notes Chestna.

Of course, the good news is that it’s lot easier to swap out a module of code than it is to return a puppy.

— Mike Vizard

April 18, 2018
5 Resources for JavaScript Developers

Javascript (JS) is one of the most widely used and beloved programming languages in history. This can be attributed to its fairly light learning curve and impressive functionality. Designed by Brendan Eich in 1995, the language has seen steady gains in use for more than 20 years.

JS itself is a high-level and weakly typed language, which means it is powerful and less prone to errors than other coding languages. It achieved early success and is now integrated on both the client side and server side.

Most applications and OSs come pre-built with JS development capability. It has become ubiquitous in the web development market and continues to be the strongest and most popular web language out there.

With that in mind, here are five resources for JavaScript developers:

Codecademy

Codeacademy is one of the most invaluable resources a programmer can have. It offers tutorials and lessons on hundreds of topics and provides copious amounts of examples to bolster your programming skills. JS has its own page at Codecademy filled with lessons and coding tests to hone your skills and promote better learning.

Codewars

If there is anything that can hone your programming know-how in real-life situations, it’s Codewars. This handy website has weekly challenges to conquer in JS submitted by real people. It puts JS developers in the hot seat and allows them to deal with situations that they may find in real-life work environments.

It also challenges the knowledge of experienced programmers and enhances their practical skills. Troubleshooting assistance is another big help for programmers just starting out, as it helps identify the small mistakes that can prevent compiling code.

MDN

The Mozilla Developer Network (MDN) is a remarkable resource for all JS programmers as it continually updates with the best practices for coding. It has a gargantuan community and is constantly evolving to fit the needs of newer applications.

For developers, MDN provides unique and incredibly detailed documentation on everything from developing for traditional web to mobile web development. The MDN Web Docs has no equal when programming JavaScript, as it guides you from beginner to expert effortlessly, it seems.

Libraries

This is where JavaScript really comes into its own as a powerful platform and highly functional language. JS has a library for everything from GUI to to form applications.

The most popular library is JQuery, which is a DOM (Document Object Model) manipulation framework designed to make all parts of a webpage customizable. JQuery, like the other libraries, seeks to simplify syntax and provide greater readability across the platform. This makes JS an incredibly customizable language that makes coding easier without losing the functionality of the language.

Code-Alongs

One of the most underutilized tools in the programming field, code-alongs make coding much easier than trying to teach yourself from a book or learn from a lecture. During code-alongs, programmers will code live and share their thought processes as they do certain things.

This especially helps new developers who stare at a screen and can’t figure why that goes there. For experienced developers, it can offer an insight to different strategies that they might not know otherwise. Regardless, code-alongs are incredible tools made by individuals for the sole purpose of fostering a love for programming.

Conclusion

Programming jobs today usually require a knowledge of various languages, but almost always JavaScript is a requirement. Its usefulness make it one of the must-learn languages for all coders hoping to make a living. To make life a little easier, and JS a little stronger, there are many resources that can be utilized.

JavaScript is an incredible programming language entirely deserving of its recognition. It is also a necessary tool for programmers of all styles and philosophies. To that end, resources abound for JS and should be used to their fullest. The true usefulness of JavaScript is its amazing community and incredibly involved developers that make JS the programmers dream. If there is any language you should learn now, it’s JavaScript.

— Josh Althauser

March 30, 2018
Salesforce Details Integration Plan Post-MuleSoft Acquisition

Salesforce this week announced it will plunk down $6.5 billion to acquire MuleSoft, a provider of application integration software currently used by more than 1,200 organizations. Once the deal is complete, MuleSoft will continue to operate as a unit of Salesforce with current MuleSoft Greg Schott continuing as CEO.

However, there will be two integration platforms once the merger is completed: MuleSoft will continue to offer its Anypoint platform that can be deployed on-premises or accessed as a service, while Salesforce plans to unfurl a separate Salesforce Integration Cloud based on the Anypoint platform.

Schott said the merger will accelerate digital transformation projects that in many cases are hampered by developers writing custom point-to-point code at a cost of more than $400 billion a year. By relying on an integration platform, he said, organizations will be able to take advantage of an application network to unlock the value of data locked in legacy systems faster using a standard set of application programming interfaces (APIs) than they would if the two companies had simply decided to form a technology alliance.

The reason for two separate integration platforms comes down to how different customers engage with MuleSoft and Salesforce, he said. The two companies have a roughly 60 percent customer overlap. That means a significant portion of the MuleSoft base is not integrating applications involving software-as-a-service (SaaS) applications from Salesforce. The Salesforce Integration Cloud will be targeted specifically at customers that are, for example, making use of Salesforce Lightning low-code application development tools to create applications that extend the core capabilities of the Salesforce application portfolio.

In addition, MuleSoft provides a complementary capability to the Heroku platform-as-a-service (PaaS) environment that Salesforce already owns.

Salesforce estimates moving into the application integration space will increase the size of its available market by more than $20 billion through 2022. But the company acknowledged that MuleSoft has as of late been operating at a minimal loss—its sales grew 58 percent last year to $297 million, but that’s a fraction of the total available market. Salesforce is betting that its sales staff combined with an ecosystem of partners will be able to drive the revenue MuleSoft currently generates higher by several orders of magnitude.

However, competition across the application integration category is fierce. Not only is there no shortage of options, but many developers often prefer to write custom code than incur the cost of employing an integration platform. As digital business transformation projects accelerate, Salesforce is essentially arguing that the pace of integration required will make it impractical for developers to continue writing custom code. The rise of microservices also creates a requirement for integration at a level of scale that is difficult to keep pace with when employing custom code.

The degree to which digital transformation coupled with microservices will transform application integration remains to be seen. But it is apparent that the need to integrate disparate sets of code using a structured set of DevOps processes has never been greater.

— Mike Vizard

March 21, 2018
NodeSource Increases Metrics in Node.js Development Platform

As reliance on Node.js to build applications in the enterprise has skyrocketed in recent years, the challenges with managing these applications have been manifold, because most existing tools don’t provide much visibility into Node.js applications. To help address that issue, NodeSource has revamped a development framework based on Node.js to make it easier to manage deployments of Node.js applications at scale.

NodeSource CEO Joe McCann says N|Solid 3.0 includes a revamped user interface and enhanced dashboard through which thousands of processes can be monitored. DevOps teams now can choose from more than 50 metrics to explore relationships between application data. In addition, all of the snapshot and profile assets can be downloaded, sorted, deleted or marked as favorite. Previously, the dashboard could only monitor up to 250 processes.

The latest edition of NodeSource also provides support for alerts that can be used to trigger notifications in the event certain thresholds are exceeded.

Fresh off raising an additional $17.5 million in funding, NodeSource has been making the case for an enterprise-class implementation of Node.js for several years. It counts Citadel, Comcast, Condé Nast, Delta Airlines, Goldman Sachs, Mastercard and PayPal among the organizations using its platform.

NodeSource captures application metrics using agent software written in C++. The idea is to replace an open source implementation of Node.js with the version developed by NodeSource that is integrated with that agent software.

As a variant of JavaScript, Node.js is essentially delivering on one of the original core promises of Java by making it easier for developers to build applications that can run on both clients and servers. Variants of JavaScript may not be as robust a framework for building applications as Java, but as programming environments go, JavaScript variants are much more accessible. According to the Node.js Foundation, the arm of the Linux Foundation that oversees the Node.js framework, there are more than 15 million downloads of Node.js per month.

Most of the Node.js use is driven by developers who don’t always appreciate operational management issues. Many IT organizations have been hesitant to more broadly employ Node.js because they lack the tools needed to manage Node.js applications at scale. NodeSource is now trying to address that issue by embedding management tools in its core platform.

By embedding many of the management tools needed to manage Node.js at scale, NodeSource is hoping senior-level IT managers will adopt its platform as a corporate standard instead of continuing to allow developers to pick whatever flavor of Node.js they find. Naturally, increased usage of Node.js is drawing interest across a broad spectrum to DevOps tool providers, so the issue many IT organizations must evaluate is the degree to which they can rely on existing DevOps tools to manage Node.js applications. NodeSource recently integrated its platform with the application performance management tools provided by AppDynamics. Because developers are now being held more accountable for the performance of their applications, NodeSource is betting that the metrics it provides will also appeal to enterprise developers.

The degree to which Node.js will become a de facto enterprise standard remains to be seen. Contention between various programming language camps is fierce. But at the very least it’s already apparent that Node.js applications in the enterprise are here to stay.

— Mike Vizard

January 11, 2018
The Executive’s Guide to Microservices Chapter 2: The Business Challenge
Steve and team have been working diligently to analyze the intricate web of code that has been organically developed over the past 12 years to design a program to modernize the application. Application is actually a poor name for all that Steve and his team manages. Steve’s team manages a complex custom supply-chain system that manages inventory, warehouse, picking, packing, shipping and order management. A hiccup in any module could lead to a serious financial impact to the business.

The business has discussed multiple times over the years switching to a commercial product, such as Manhattan or SAP, but the costs and challenges of doing so without interruption to the business resulted in a decision to keep maintaining the current system. The business has been judicious in its requests to update the system, understanding that changes take a long time to implement and test due to the design. However, competition from major online retailers are starting to seriously impact profitability, forcing the business to make a considerable investment.

The supply-chain system is comprised of multiple modules mostly written in the Java programming language, but some of the older modules are in C++ and require a Windows Server operating system. This combination of technology has been a source of strife for Steve’s team. They have tried multiple technologies over the years to make the system more stable and to isolate the older C++ modules in a way that reduces risk of downtime should they crash. The Java modules were written to run inside of a web application server, which provides some linear scalability, but it’s still an issue to scale the C++ modules in a relative manner. Now, increased demands from the online channel is stressing the system in ways that it was never designed to handle.

The business has asked Steve to provide a comparison of costs and resources needed to migrate to a commercial system versus modernize the current system. However, there is one constraint that is limiting the business moving to a commercial version at this time: There are five months until the winter shopping season freeze, when all changes must be completed with no further changes to the systems until February of the following year. Most of the time estimates from integrators for the commercial version are more than 12 months in duration.

Steve’s company is really between a rock and hard place. If it doesn’t fix the system Steve is managing, it may not be able to scale to the volumes the company needs to be profitable this holiday season, but the company has waited so long to decide to move to a commercial package that it won’t be ready in time for the holiday buying season regardless.

Likewise, Steve and team are in a similar difficult position. Their efforts around a modernization program have yielded some potential wins that could allow the business to achieve many of their desired outcomes before the winter shopping system freeze. However, there is a culture of fear that permeates Steve’s team. Whenever this system has failed in the past, there were significant reprisals from the business in the form of multi-day “all hands on deck” sessions, where the entire team was expected to be there from 7 a.m. until 8 p.m. until the system was operational again, not to mention letting go those who introduced bugs into production releases.

Stacey is Steve’s head of development. She brings the modernization plan to Steve for review, but makes it clear that the team believes there are some potentially high risks associated with the approach. While the Stacey and team believe they will be successful, they want assurances from the business that they have the leeway and support to take the risks without reprisal. In return, Stacey tells Steve that there ares certain changes that the team will implement to limit downtime if something should occur:
1. They will adopt a strategy that developers are responsible for fixing anything they break.
2. They will be implementing a new continuous integration and deployment tooling that will automate the integration build, unit testing and review of any code changes speeding release of updates and fixes into production.
3. They will be adopting the Agile Scrum software development life cycle to deliver functional changes every two to three weeks.
4. They will set up a Kanban board online that will allow the business to track and understand where the proposed capabilities are and when they will be completed.
5. Before each sprint the business will have a chance to reprioritize any features or capabilities so as to ensure that the most important features get completed prior to the system freeze.
Steve likes Stacey’s plan and agrees to take it to the business. He explains to Stacey that there will be a natural tendency to push back, but given the urgency and lack of options, this may very well be the best time to push for these changes in their company. In the past, there has not been a lot of tolerance where IT systems impacted financial performance. It’s now Steve’s job to help the business understand that, with the growing dependency on software in business, its expectations need to change for the business to successfully compete.

— JP Morgenthal
December 18, 2017
DevSecOps: Security Needn’t be Sacrificed for Speed

With the right practices, security needn’t be an impediment to continuous development and rapid improvement.

The same cycle keeps repeating, according to IT security and risk management consultancy Sense of Security co-founder and CTO Murray Goldschmidt. A new technology is hyped, leading to rapid adoption, but security is left as an afterthought. It happened with WiFi and voice over IP (VoIP), he says, and is currently happening with the internet of things (IoT). But it doesn’t have to be that way.

DevSecOps: DevOps + Security

DevOps is good for making things better, faster. But there tends to be a culture clash between those talking about speed, velocity or agility and those concerned with issues such as control points.

So Goldschmidt and his colleagues are showing their clients how security can be integrated into DevOps (DevSecOps) in an automated manner without affecting velocity.

Most people with development, operations or cloud backgrounds aren’t well-versed in security, he suggests, so Sense of Security shows clients how DevSecOps means security and DevOps can run in parallel.

“It’s not that complicated,” he says, but it’s something most people don’t think about.

Organizations often have a vulnerability management life cycle to identify and treat issues. After all, that’s part of various industry standards.

The typical approach is an annual penetration test to find issues, which can then be addressed.

A better way is to move to automated testing, and there are various commercial and open-source products to do that job. Goldschmidt says he sees little resistance to this idea.

The next step is to go from scheduling these vulnerability scans on a quarterly basis to weekly or daily—or even to run them continuously.

Citing the Struts vulnerability that caused a big problem for Equifax, he notes the challenge is to identify vulnerabilities in your systems before an attacker does. Continuous automated scanning means the window of vulnerability is very narrow.

This idea is simple enough, he says, but for some reason it doesn’t occur to most people until someone brings it to their attention.

When a scan reveals a vulnerability, its significance (severe, medium, etc.) is used to prioritize remediation.

“DevOps guys understand those triggers,” he observes: If you give them the data, they can take the necessary actions. For example, that might mean shutting down the servers in a small web farm one at a time, applying the patch, restarting and moving on to the next. They could all be patched and running by the end of the day.

Patching Isn’t Everything

However, “it is unfair to assume organizations can patch things quickly” every time, he says. For example, the Struts vulnerability required more than just a patch—the code running on it had to be recompiled and tested, and that process could take months in a large organization.

So organizations should not rely on the idea that patching is the fix for a vulnerability. While patches will be applied eventually, if you can make it difficult to actually take advantage of any exploits, the risk of data breaches is very low.

One very easy-to-implement example of these measures is using a stateful firewall to ensure inbound-only access to web servers. By disallowing outbound access—”the channel through which data is lost”—there is no path for data to leave.

Goldschmidt also recommends using tools to examine in-house code and the open-source and commercial code that is used with it. Such tools can detect most common problems, including openings for SQL injection, cross-site scripting and token misuse.

He describes these tools as being the equivalent of “spellcheck for developers,” and says it reduces the likelihood of putting insecure code into production.

The market includes products from Veracode (now part of CA), Sonatype and Qualys.

Qualys, he notes, provides differential reporting. This makes it obvious that something has changed, and “that is the key to automation.” Whether the system itself has changed or new information has been discovered about vulnerabilities or configuration issues, action is required.

Furthermore, the ease of making configuration changes that could have security implications makes continuous scanning even more important.

These checks should not be limited to individual modules. Rather, they should be repeated—preferably automatically—as modules are assembled to help developers avoid poor code and to check the overall product.

RASP Away Some Attacks

Runtime application self-protection (RASP) is another technology Goldschmidt advocates. The idea is to detect abnormal and possibly malicious activity. One example is that normal operation would see an application communicating with its application server, and the application server communicating with the database. If the application suddenly makes a direct request to the database—as happens in an SQL injection attack—action is clearly required.

Depending on the situation, RASP might raise an alert or immediately terminate the application, among other possibilities.

The use of these and other technologies and techniques should allow organizations to run at the pace implied by DevOps without sacrificing security.

— Stephen Withers

November 20, 2017