devopsy.kinsta.cloud

Tag: devsecops

The Secret to Winning at DevOps: Are You Up for the Challenge?
The main idea behind DevOps is to enable companies to keep up with the increased software velocity and advancements in agile culture for a smoother end-to-end software delivery cycle.

The main goal of DevOps is to accomplish integration and automation, which is why implementing this philosophy can be challenging. Not only do you need to replace older methods and practices, but you’ll also have to change the mindset of the developers and the operations team to ensure they work in sync.

Several IT operations teams and software teams have adopted DevOps practices into their work culture for faster evolvement and improved innovations. The pipeline comprises continuous integration, testing, deployment, as well as monitoring application and system performance.

Introducing new DevOps tools and changing the mindset to prepare teams for the fast-paced world remains crucial for a successful implementation.

Despite the revolution that this philosophy brings to software development, several enterprises find themselves taking DevOps to an unproductive extreme. To remain productive, one of the aspects that teams need to work on is reducing rework, and the best way to ensure this is automation.

Understand How DevOps Works

Under a DevOps model, the development and operations teams are integrated into one to prevent them from getting siloed. This also improves collaboration and productivity.

You see, it brings alive the possibility of both the teams thinking more alike, working together and sharing responsibilities. This is done by automating code testing and workflows, automating infrastructure and continuously measuring application performance.

In some models, even the QA and security teams merge with the dev and ops. In cases where security becomes the primary focus, the name gets modified to DevSecOps.

In essence, the focus of DevOps is on automating processes that were otherwise manual and slow. Teams use a technology stack and tooling that can operate and evolve applications more reliably and swiftly. As engineers will be able to accomplish tasks such as deploying code and provisioning infrastructure faster with reduced issues, teams can reach testing and maintenance stages quicker.

Balance Between Standardization and Adaptability

Software products are mostly developed from the customers’ perspective, and if not, from end-user experience. Often, developers work backward to identify customer needs and wants for ascertaining successful innovation.

One of the biggest challenges when developing a software development life cycle (SDLC) strategy for organizations is to consider dynamic customer needs, strict compliance policies, unpredictable market trends and company goals. To ensure a consistent workflow, DevOps teams need to adopt standardization. In fact, workflows, technologies, processes, protocols and metrics need to be standardized before they can be automated.

This is also the main reason why organizations adopting DevOps need to strike a balance between standardization and adaptability. One industry that has excelled at this has been the financial industry, which has been leading the charge when it comes to adopting the latest software delivery practices and technologies, including DevOps. Financial executives view DevOps as being a way to improve security and risk and governance strategies.

The result is that cloud-based financial services are now automating virtually all of their processes through their software delivering pipelines, which makes tasks such as scanning receipts, sending invoices, tracking expenses or making payments seamless as they sync to your account. This simpler process is beneficial for boosting developer productivity and resource utilization, and for enabling enterprise scale management. If anything automating processes is becoming necessary for achieving higher product quality, compliance and scalability.

As mentioned above, new DevOps tools need to be introduced to team members to keep up with the constantly evolving strategies and implementation. But to prevent the creation of silos between teams, mechanisms need to be developed to make the adoption of new technologies easier.

Achieving the delicate balance between standardization and automation will help eliminate communication gaps, performance bottlenecks and silos between the different teams.

Benefits of Automation in the DevOps Landscape

The following are the advantages of adopting a DevOps philosophy:
- Code Development. Source control will keep everyone in the loop by managing, tracking and documenting any changes in code. This can be time-saving, and reduce the complexity of software projects.
- Smoother Testing. Testing is a continuous process in DevOps frameworks that includes system communication, several test integrations, predicting and tracking issues, and integrating approved automated builds. In the absence of automation, executing and managing continuous testing could be a rather tedious job that might cause problems between developers and the operations team.
- Better Visibility. The main job of the ops teams is to be aware of the code changes, ongoing problems and the impact of a specific code on the end goals. Plus, when they operate in a DevOps environment, they need to keep the developers in the loop as well.
  For example, if a system administrator from the ops team identifies code issues weeks after submission, it puts more pressure on developers. Now, the developers have two jobs: solve the problem in the previous code, and simultaneously work on making progress with the new code. This is what gets time-consuming, which can harm the company’s market standing. To remain ahead in the competition, innovation needs to be frequent and accurate.
  When there is a constant feedback loop between the dev, ops and QA, bottlenecks, and silos are eliminated, productivity is improved and customers are happier due to quicker innovation.
- Continuous Integration and Delivery. Automation can help deliver appropriate software built, data, code changes and tests to target environments. An example is how web hosts for e-commerce businesses need to be updated frequently for robust deployments. Automated testing will help ensure that code is delivered properly and doesn’t introduce new bugs, thus creating a platform with a superior user experience.
  This, in turn, helps DevOps teams to introduce frequent software changes by deploying error-free codes and continuous testing.
- Data Processing and Monitoring. The teams also need to measure and monitor the performance of their environment, which can be done by reading and analyzing system logs. But the existence of hundreds or thousands of servers in the environment can make it complicated.
  Automation will allow the teams to make sense of all the data and let them know how an application is performing and whether there are any bottlenecks.
Getting the Balance Right

Organizations need to realize that automation involves placing technologies around once-manual processes. The catch here is as the processes will become inherently repeatable, they need to be correct. Otherwise, organizations will only have flawed processes running faster, which will ultimately defeat the purpose of adopting DevOps in the first place.

Companies need to understand adaptability as well. This can be done by mixing both the old as well as new systems. For this purpose, an inventory of all applications, data stores and development processes for promoting meta development processes that include design, development, testing, deployment, configuration management and so on can be made.

In the end, the secret to winning DevOps is aligning DevOps tools with your organization’s goals – not following the footsteps of other organizations.
June 23, 2020
Participate in the Checkmarx 2020 Survey
Checkmarx, the global leader in software security solutions for modern enterprise software development, and devopsy.kinsta.cloud are conducting a survey about the implementation of DevOps and related automation and security tools.

The purpose of the survey is to help organizations evaluate their DevOps maturity, find out what are the most used DevOps tools and the most common challenges organizations are facing with their current DevSecOps model.

The survey consists of 16 short multiple-choice questions. The results will depend on several factors including:
- The organization’s progress on their DevOps adoption journey.
- The role of the respondents in their organization and their responsibilities for DevOps transformation.
- Automation and security tooling capabilities respondents are using for DevOps and cloud-native applications.
- The respondents’ ability to overcome challenges and obstacles standing in the way to successfully implementing DevOps.
We urge everyone in the DevOps space to participate in this survey. The more data we can gather, the more we’ll find out about the adoption of DevOps and AppSec tools. We’re counting on you to make this report even more valuable. Invite your friends and colleagues to contribute to the survey, too — the more the merrier.

Click on this link to complete the survey.

We will make an announcement when the report is ready. Stay tuned!
June 19, 2020
What Developers Really Think About Pentesting

A developer in their natural habitat is often spotted in a state of deep concentration, coding awesome features to tight deadlines. Feature-building is often our favorite part of the job, and really, it’s the fundamental outcome of the software development life cycle (SDLC).

However, as we have discussed before, many of us are still prioritizing features over security best practices. After all, in most organizations, it is set up to be someone else’s job and adequate security training for us is limited. Penetration testing and static analysis scanning tools (SAST) are just part of the overall process to mitigate security risks, operating rather independently from what we do — until the code bounces back to us for hotfixes, of course.

It’s at that moment that many developers think, “Do the pentesters hate me?”

These interactions often define a team and culture. The concerning thing is, the lack of communication, understanding and overall collaboration has created tension, at least on the side of the developer.

Think about it: Imagine you’ve spent a few hundred hours sculpting a marvelous statue, and then someone comes along with a hammer and starts smashing bits off it after they’ve told you its foundations are not up to scratch. That’s the perceived dynamic between a tester and developer — the latter has their software darlings slaughtered by an outsider that hasn’t labored through the process with them; instead, they’ve extended the workload and delayed the satisfaction of shipping code.

Having moved into the security space long ago, I can see both sides of the story. And no, pentesters don’t hate developers. The pentester is in all likelihood, overworked and under a lot of pressure. As such, a constant stream of common security bugs that could be quite easily fixed at the code level take up time, resources and headspace away from the really serious issues.

I always saw pentesters as kind of like parents. They want you to do well, and when you don’t they’re not mad, just disappointed.

Now that I’ve put that (perhaps slightly unfair) image in your mind, let’s explore this a little deeper. What has caused this world view among developers?

Resentment for Being Told What to Do

Nobody likes feeling as though they’ve done a bad job, or that someone doesn’t like their work. Sadly for developers, when static analysis and pentest results come back to them, it can feel like a report card. They’ve been given low grades, but at the end of the day, their bosses assess them on the features they’ve built and the time they’ve delivered them, not whether there were vulnerable elements in the software or not.

For the poor pentester, this is a case of “don’t shoot the messenger.” It’s nothing personal — they are tasked with finding bugs, and they found them. Granted, at a person-to-person level, maybe some pentesters are grumpier than others, but they’re not (or shouldn’t be) out to crucify development teams. It would be far easier for both teams if they were on the same page with what constitutes security best practice. Developers are not expected to be perfect; realistically, the testing team is there to protect them from shipping vulnerable code.

Minor Issues vs. Higher Priorities

It’s true, a developer’s highest priority will always be the building of features, and in this crazy world of rapid digitization, it will have to be done at speed. While some coders have a personal interest in security and secure coding, the general sentiment is that security is “someone else’s problem,” which inevitably includes pentesters.

Most common vulnerabilities are indeed minor issues to remediate — once known, the fixes are simple to execute for things like cross-site scripting (XSS) and SQL injection. The problem is, many developers don’t realize they’re introducing them in the first place, and these seemingly minor issues are the small window of opportunity an attacker needs to cause devastating problems for a company. According to Akamai, between November 2017 and March 2019, SQL injection vulnerabilities accounted for 65% of all web-based attack vectors. For a vulnerability that has had a known fix for more than 20 years, that is a sobering statistic.

Some pentest teams do assist in the remediation of security bugs, but others will provide a report of the bad news and expect developers to work through hotfixes, even if they have moved onto a different project by the time this happens. And in some cases, the development team may be faced with a report that includes bugs they can’t (or shouldn’t be expected to) fix. It still has to be part of the findings, and again, not taken personally.

The “happy medium” for this would be pentesters, security personnel and development managers acting in more of a mentor role to ensure the team has what they need in terms of effective training and tools, giving individual coders the best chance to succeed and code securely from the very beginning of the SDLC. Both teams really should be meeting half-way to ensure security is considered from the start, as part of a healthy DevSecOps practice.

Lack of Knowledge vs. False Positives

Static analysis is an element of the security process in the SDLC, and static analysis scanning tools (SAST) play a fundamental role. And yes, false positives are an issue with these and other types (DAST/IAST) of scanners. It’s an annoyance in what is already a slow process, requiring manual code review and putting pressure on both developers and pentesters alike. Pentesting personnel have taken time to meticulously set up custom rules to avoid inaccurate readings and provided company-specific guidance, yet some false readings slip through and end up in front of a head-scratching developer.

This process isn’t perfect, but the other problem is that many developers lack enough knowledge to mitigate a lot of common vulnerabilities on a consistent basis. With security training rare in tertiary education, and on-the-job training varying in its effectiveness, it stands to reason that there may be some overconfidence at play as well (and it’s not their fault, we as an industry need to get better at equipping them with what they need).

Remediation Tasks

Sometimes, there is an assumption by overworked engineers that pentesters are just hanging in the wings, waiting for the moment to strike by testing an application and raining on the development team’s parade. They are over-testing, they’re nitpicking, they’re creating extra work.

The only problem with that is they, too, are overworked (more so, in fact, the cybersecurity skills shortage is at dire levels and getting worse) and simply don’t have the time to test without reason. They are not the sole decision-makers in prioritizing testing; it could have been requested by senior leadership, a customer, as part of a security audit or even determined as a result of a bug bounty program.

For a developer, being pulled off current feature-building sprints to work on security fixes is annoying — especially if it’s not their work. Perhaps a previous team did the last update, or another vendor. However, security is everyone’s problem. That doesn’t mean every developer has to take ownership of security bugs as though they have made them all themselves, but they do need to come to the party in terms of security being a shared responsibility.

Where to from Here?

Sometimes, a mindset shift can be all it takes to make significant headway in solving a problem. We’ve talked about the rather frosty reaction a developer has to less than favorable pentest results, but what if they could turn it into a challenge? Perhaps they could think of the pentester as a friendly competitor; someone they can beat at their own game. After all, a security-aware developer that can eliminate common bugs as they write code is going to make their job much more difficult. By contrast, a developer with no focus on security is going to be comprehensively bested by their pentester counterparts when they can easily break their software.

Pentesters and developers may not be joined in harmony 100% of the time, but their relationship can be vastly improved when an organization addresses security as a key priority, and empowers teams with the right knowledge and tools to succeed — especially developers. It comes down to whether a company-wide, positive security culture is a priority, and if we are to fight the (currently) losing battle against common vulnerabilities, it absolutely should be.

June 17, 2020
Why DevOps and Federal Agencies Need Each Other

In times of crisis, the U.S. government needs to bring in tech tools fast to help solve the problem.

First, now is a vulnerable time and weaknesses are exposed in telework infrastructure as the government rapidly shifted to remote work. Cyberattacks are up as adversaries try to exploit the weaknesses. Second, federal agencies are also overloaded with traffic, to the point that their technology is reaching a breaking point.

DevOps and DevSecOps may be the key to solving these issues for government agencies. Both, DevOps and DevSecOps, ensure delivery of a product is fast, secure and constantly evolving, which is vital to helping the U.S. government maintain continuity during the ongoing pandemic and set up future stability.

The Air Force experienced these benefits firsthand when its internal DevOps team pushed out at least 10 updates a day, sometimes up to 30, and sustained that agile standard for some time. This agility, security and speed allows the Air Force to focus on the end-users and mission owners.

If the government doesn’t have DevOps, it will lack the foundation needed to build a strong tech stack and work with other emerging tech solutions.

DevOps Use Cases in Government

With the government workforce spread out geographically, government networks are experiencing an increase in users plugging into virtual environments. Continuous patches and updates keep government systems and networks secure, functional and able to handle the load that comes with a surge of users. DevOps ensures the government has the tools and processes in place to support growth and prevent network failure under the additional stress of onboarding thousands of users each day.

The government also needs tools that can help the distributed workforce maintain continuity, especially when it comes to security, operations and maintenance. Employees need correct access to do their jobs, but agencies must maintain control over what data is shared and how to confirm users are who they claim to be. Access management is vital in remote environments to ensure tighter control over who has privileged access.

A modernized approach to privileged access tools means developers can hit targets of continuous delivery to improve systems and security. Otherwise, exploitable vulnerabilities are exposed to bad actors. Solutions for secure privileged access, especially across a distributed workforce, are key to scaling tech across government.

With a hasty shift to remote work also comes change management, which is already difficult, not to mention the additional strain of a pandemic. In a crisis, federal agencies can’t wait for in-house solutions that take a long time to develop. The government needs commercial tech that can help build remote infrastructure.

Federal Market Opportunities

As the government responds to COVID-19, federal agencies are in search of technologies and tools that can support their missions. Many agencies are feeling immediate strain on their IT systems as part of the shift to telework, and have received reallocated and additional budget — with broad latitude on how they spend — and procurement flexibility to modernize their systems. This opens up opportunities for tech companies, like those in the DevOps and DevSecOps space.

Tech companies that already work in the federal market know that while the government procurement process can be lengthy and complex, it can be well worth the effort for stable revenue. In times of economic uncertainty, working with the federal market can help companies build recession resilience.

Another part of the opportunity now is that the government needs flexible and scalable technologies that can help them respond to the COVID-19 crisis, but first, they need DevOps tools for a strong foundation and infrastructure.

The government needs DevOps and DevSecOps now more than ever, and there are commercially successful tech companies that can help with exactly that today. In return, the government can provide a sustainable source of revenue for emerging DevOps companies. Working together can be a win-win for these tech companies and federal agencies, and can help move us toward a more innovative, safer and healthier future.

June 16, 2020
GitLab Adds Fuzz Testing to DevSecOps Toolbox

GitLab today announced it has acquired Peach Tech, a provider of protocol fuzz testing and dynamic application security testing (DAST) API testing tools, and Fuzzit, a continuous fuzz testing tool, as part of its efforts to advance the adoption of best DevSecOps practices.

David DeSanto, director of product for GitLab Secure & Defend, said the two acquisitions should make it easier for DevOps teams to incorporate both whitebox and blackbox fuzz testing techniques for security testing much earlier in the application development and deployment process.

Fuzz testing is an automated technique that involves providing invalid, unexpected or random data as inputs to software, which is then monitored to see what happens—if it, for example, crashes or a memory leak is created.

Peach Tech adds Peach Fuzzer, an automated security testing platform that employs definition files known as Peach Pits to generate the fuzzed data consumed by the test target along with a framework for automating the web application programming interface (API) security testing process.

Fuzzit provides a service that enables DevOps teams to continuously generate fuzz tests and correlate crashes in a way that can be integrated within a continuous integration/continuous delivery (CI/CD) workflow.

Once Peach Tech and Fuzzit technologies are fully integrated with each other and the GitLab platform, DeSanto said GitLab Secure customers will be able to automate myriad tasks, from security testing to vulnerability management and remediation.

GitLab will also employ technologies from both companies to further its ambitions to drive the adoption of interactive application security testing (IAST). The goal is to not only make it easier for developers to employ DevSecOps tools but also understand what issues are being created as applications are developed, said DeSanto. That approach should reduce the number of instances where development teams are continuously making the same mistakes across multiple application development projects, he noted.

The further left cybersecurity testing is shifted the less stress there will be on chronically short-staffed cybersecurity teams. The challenge is that while most organizations recognize the potential benefits of DevSecOps there hasn’t been much progress in educating developers on what issues to look for and providing them the tools needed to discover and remediate vulnerabilities.

There is, of course, no silver bullet when it comes to cybersecurity. As long as humans write code there always will be potential issues. However, many more routine cybersecurity issues should be addressed long before an application is deployed within a production environment. To achieve that goal organizations are providing developers with tools that identify cybersecurity issues as they write code in addition to incorporating more security testing into their CI/CD workflows.

Of course, GitLab is not the only provider of a CI/CD platform focusing on how to foster the adoption of best DevSecOps practices. There’s clearly a race to embed security testing tools within CI/CD platforms that should advance adoption for DevSecOps, if for no other reason than they are becoming easier for developers to discover and employ.

June 11, 2020
3 DevOps Security Best Practices Your Organization Can’t Afford To Ignore
CI/CD pipelines are at the core of daily operations for many businesses today. These processes, when set up correctly, help to keep the delivery process consistent by automating many manual tasks and providing visibility into how the software is being worked on.

DevOps is also the place in your technology stack where your infrastructure has access to many different resources, from development and production environment to analytics keys and code signing credentials. The more resources your pipelines have access to (secure secrets, proprietary code, databases, etc.), the more important it is to keep your CI/CD system secure.

In this article, we talk about the different parts of DevOps security for CI/CD pipelines and highlight a number of ways to improve on these aspects. We usually divide security practices into three parts that you can address with different kinds of solutions:
1. Secure pipeline configuration
2. Code and Git history analysis
3. Security policy enforcement
All three aspects are equally important. Let’s take a deeper look at these categories and ways to address them.

Secure Pipeline Configuration

It is possible to use your CI/CD pipeline configuration to make security issues less likely to happen.

First, safely store secrets that you use in your pipelines for connecting to databases and third-party services. Depending on the CI platform you use, you may have the option to use encrypted-at-rest environment variables, or to use the contexts feature. Contexts are used to provide access to environment variables across projects. Their use can also be restricted to specific security group members as defined by the organization’s administrator.

Another option is to use a third-party solution to dynamically fetch secrets from their secure storage for your jobs. To ensure that none of your credentials become exposed to those who shouldn’t see them, you should never check these into your repository in plain text, even if the repository is private.

Second, for sensitive files like code signing keys, I recommend adding an additional layer of isolation between your encrypted files and your repository for added security. Keep them encrypted in your repository and store the decryption key in the environment variables or contexts, only decrypting them inside your CI/CD jobs when they are needed. This makes it even more difficult to expose or leak these highly sensitive files.

Third, you never want to leave your CI/CD environment running without monitoring it. Therefore, make sure that the containers and VMs used for your pipelines are destroyed after jobs that require sensitive information finish running.

Fourth, pay extra attention to how your CI/CD system handles builds for pull requests that come from forks of your repository. If your build stages require secrets to work, forked pull requests might gain access to them through your pipelines.

By addressing these four aspects you can significantly reduce the risk of security incidents due to your CI/CD pipeline configuration. Next up, code and Git history analysis.

Code and Git History Analysis

We all love Git for its comprehensive history of changes, being able to look through the history of the project with a simple CLI command and see who has most recently changed a line of code, among other benefits. This also means that any sensitive information that makes it into the Git history can be accessible to attackers if a Git repository is exposed, even if the most recent state of the repository doesn’t contain the secrets anymore.

Trufflehog and GitLeaks are two tools that can help you identify secrets that have been committed to the codebase so that you can deactivate and replace them. These two tools will also scan your Git history for traces of secrets that your team might have added to the repository in the past.

Once your Git history is clear of secrets, you can proceed to the next level: making sure that your current revision doesn’t contain any vulnerable dependencies.

Static Application Security Testing (SAST) techniques can look through the application in your commit and analyze its dependencies. If any dependencies contain any issues or known security vulnerabilities, your commit will be marked as insecure and won’t be allowed to proceed to deployment.

Dynamic Application Security Testing (DAST) techniques go one step further and spin up a copy of your production environment inside your CI job in order to scan the resulting containers and executables. The dynamic aspect helps the system catch dependencies that are being loaded at launch time, for example, as those won’t be caught by SAST.

Security Policy Enforcement

Some security aspects can’t be statically checked based on known vulnerabilities, but rather are specific to your particular company, and therefore need to be codified as policies. These can take the form of automated or manual compliance checks.

Certain tasks such as reviewing the list of all accounts that have access to your repositories, or making sure your onboarding and offboarding processes are in sync, will be manual. We recommend that you set reminders to perform these regularly.

Some tasks actually can be automated quite easily. For example, third-party services can provide a convenient way to codify a set of rules that will be matched against in your CI pipeline, e.g., proving compliance with the regulations that govern your data. If there is a mismatch, the build will fail.

Some of the Important Parts Can’t Be Automated

Keeping your CI/CD pipelines secure is more important today than ever before as automating your CI/CD practices requires more access to development and production environments, analytics keys and code signing credentials than in the past. The hard thing about security is that if you only get one of the three categories right, you won’t be 33% secure. You will be 0% secure until you get all the bases covered.

With the approaches outlined above, you’ll be in a much more secure position than you would be without them. However, some of the aspects that matter the most for CI/CD security can’t be automated or detected with an automated policy. These aspects are shaped by the behavior and culture within your team.

A DevSecOps Mindset

Your team is your most valuable set of security researchers because they know your applications best and constantly work on them. Have you implemented a clear process for your teammates to report security issues if they find any, and do you dedicate time to fix the security flaws they find? Do you celebrate those who report issues openly? In many companies, the answer isn’t an immediate “yes” to these, and it should be.

How long does it take for someone on your team to report suspicious activity? Do they need to post in multiple Slack channels to get attention, or is there a streamlined process to get an issue like this looked into? How do you treat those who report false positives — do you blame them for wasting the team’s time, or do you hold a blameless post-mortem so that everyone on your team learns from the mistakes? All these questions can make or break your security-minded development culture.
June 11, 2020
DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

Despite most developers and managers being well aware of the concept of DevSecOps, it is still often confused with a number of related processes and concepts. This is particularly true for the Department of Defense (DoD) contractors because they have long been encouraged to use a related process known as agile development.

Since agile development has been around for more than a decade, there is a tendency for organizations to regard DevSecOps as an extension, or even a synonym, for it. In reality, though, the two approaches are distinct. The objectives of both approaches are similar: balancing speed and agility, detecting risk early and both focus on cloud-native security and performance.

However, while DevSecOps does build on some agile development principles, such as the continuous integration and delivery of software systems in cycles, its key emphasis from the beginning of the process is to integrate security features, while Agile only focuses on delivering software.

In this article, we’ll look at the key differences between agile development and genuine DevSecOps processes, and how each complements the other.

DevSecOps vs. Agile Development

The difference between DevSecOps and agile development methodologies can be understood in reference to one aspect of software development: security. When, where and who implements security in software development varies between the two approaches.

Agile development methodologies focus on iterative development cycles, in which feedback is continuously reintegrated into ongoing software development. However, even in mature agile development processes, security is still often added to software as an afterthought. This should not be read as blaming software developers for often underestimating the potential harm from malware or overlooking the importance of cybersecurity.

Rather, in many firms, it is simply not the responsibility of developers to think about the security implications of their code, because software will be passed to the security team before release.

DevSecOps takes security and puts it on the same level as continuous integration and delivery. DevSecOps methodologies emphasize security at the very earliest stages of development and make security an important part of overall software quality.

In essence, these approaches shift the program manager’s perspective away from making sure that software is in compliance or meets a specification or audit, to ensuring that the code is written correctly and securely and that it’s deployed in a repeatable manner.

The Changing Culture of the DoD

The adoption of DevSecOps methodologies is critical for DoD contractors because these methodologies reflect DoD’s own modernization strategy. Following high-profile vulnerabilities being discovered in all types of systems, DoD seems to have released that cybersecurity weaknesses are not just a potential threat to critical defense data, but also impose a significant operational bottleneck on the continuous delivery of functionality.

At the moment, even those firms who possess a mature agile development framework can find that the multiple security checks and compliance processes that must be performed on software, prior to shipping, can detrimentally impact on their ability to deliver iterative software improvements. This is the issue that the transition to DevSecOps seeks to overcome, by attempting to shift organizations’ approach to cybersecurity away from compliance, and toward genuine security consciousness.

At the same time, analysts are aware that shifting responsibility for cybersecurity onto developers will be uncomfortable, and potentially dangerous, for many DoD contractors. Developers working on the base code for military software do not have – and are not expected to have – an exhaustive appreciation of all of the contexts in which this will be deployed, and exactly which systems their software will be required to interface with.

Automation and New Models

In response to these concerns, DoD contractors are reappraising the DevSecOps model and thinking seriously about how it can be deployed in contexts where continuous service delivery is key. There are three key ways in which this is happening.

The first is the rise of automation. The types of large-scale, multicloud infrastructures that most contemporary DoD projects rely on can often necessitate repetitive, ongoing maintenance and security assessment across both development and security teams. DevSecOps replaces these human checks with automated systems: Instead of requiring a person to go through checklists of hundreds of controls, this is done automatically as part of the software development and supply process pipeline.

The second key element in the transition to DevSecOps is endpoint security. The types of monolithic development processes that DoD contractors traditionally worked with are not suited to the contemporary deployment environment of many DoD projects. In these traditional methods, systems were built as discrete holes, with no expectation that data would be exposed as it moved between components.

This is now an obsolete approach: In DevSecOps processes, virtual private networks are used to provide security and encrypt data as it moves within a network, and the principle of least privilege reduces staff access to small portions of It environments.

Thirdly, a new generation of younger military and civilian personnel in the DoD, many of them trained in the commercial sector rather than entering the military directly from college, are bringing corporate approaches to the development of military software. This is seen in the exponential increase in the utilization of cloud services in DoD applications, and more dynamic and distributed managerial frameworks that distribute security responsibility across entire organizations, rather than having this as the sole remit of a dedicated security team.

Get Support

Moving to a truly DevSecOps methodology is likely to be a challenge for many contractors. However, just as in the last decade many firms have had to redesign their development lifecycles in order to be agile, now they will need to achieve secure development lifecycles in order to stay competitive.

If you are looking to make this shift, you should also recognize that you are not alone. DoD is working actively with its partners in order to facilitate the roll-out of DevSecOps processes and to make commercial tools and techniques available and useful for military contractors because the department recognizes the value of this methodology for the software they commission.

This is seen most clearly in the recent updates to Microsoft Azure Government, though you should also be aware that many of the resources recently released by the Defense Logistics Agency are also focused on the transition to DevSecOps.

In short, whilst the transition to DevSecOps may be challenging, it will be no more so than the earlier shift to agile development. To make this shift, however, firms should draw on the resources available to them, recognize the value of integrating security into their development workflows and build on existing agile frameworks.

June 3, 2020
How DevOps Powered by AI and Machine Learning Is Delivering Business Transformation

The use of artificial intelligence (AI) and machine learning (ML) is fundamentally changing the way we think about DevOps. Most notably, it is delivering a new form of DevOps that recognizes the need to have systems that are intelligent by design and underpinned by comprehensive security (DevSecOps). For many, this will be the crucial next step if DevOps is to shorten the software development lifecycle for all connected intelligent systems, ensuring the continuous delivery of secure high-quality software.

By now, most organizations understand DevOps is a substantial discipline that they must adopt – according to Deloitte, organizations adopting DevOps see an 18%-21% reduction in time to market. By breaking down the silos between business and IT operations, DevOps can ensure consistent levels of productivity, efficiency and service delivery, all of which hold weight in these times of heightened uncertainty.

To put it simply, DevOps can help businesses compete in already congested marketplaces. Through a foundation of continuous integration (CI) and continuous delivery (CD), organizations can ensure the customer receives the product they demand in the fastest time possible, while mitigating any elongated frustrations experienced from a lack of harmony between systems engineers and operations teams. Incorporating AI and ML into that DevOps strategy will take things to the next level.

AI and ML Are the Next Evolutionary Step for DevOps

Today’s companies are data-driven and being built as digital platforms. However, just 28% of organizations are currently succeeding in their digital transformation journeys. Increasingly, corporations are looking at what AI and ML can do to help them realize their transformative ambitions.

Both the AI and ML markets are expected to experience huge growth over the next three to four years. Analyst firm IDC, predicts worldwide spending on AI systems will reach a href=”https://www.marketresearchfuture.com/reports/machine-learning-market-2494″>42.8% by 2024.

What AI and ML reveals for these companies, and the increasing value of what Al, ML and devices can do together, are changing the way organizations view the world as they digitally transform. Coupling AI and ML with DevOps will lead to a significant shift in what DevOps gets involved with.

Primarily, it sets DevOps front and center of an organization’s wider digital transformation ambitions. If digital companies run on living data, then the development of these intelligent systems is an enticing environment for DevOps to prove its wider value to the organization like never before.

Security Takes the Center Stage

According to a TechTarget survey of key IT decision makers, cybersecurity and risk management were found to be the number one area for spending this year, with more than 53% of respondents saying they saw budgets increase in this area. And security is a crucial element that any organization employing a DevOps strategy should be considering.

DevSecOps is the simple premise that everyone involved in the software development cycle is responsible for security. In fact, the saying “security is everyone’s responsibility,” is a mantra that has been repeated often, and just as often ignored. Embedding security within every part of the development process, ensures security and compliance monitoring tools keep pace with the speed and agility that DevOps offers. It is a common understanding that security is the biggest block to the rapid and seamless development and deployment of systems, as security solutions have not traditionally been built to test and code at the speed DevOps requires.

Ultimately though, more automation from the start, reducing the need for manual configuration from security architect is where DevSecOps shines. This reduces the chance of misadministration and occurring faults, which can lead to downtime, and potential breaches or attacks. Quite often, the best ways to secure your organization is through simple hygiene factors, such as regular patching and software updates.

The reality is that every organization employing DevOps should really be approaching it as DevSecOps. Security is of ever growing importance to each and every organization and, through empowering it with AI and ML processes, it can be enhanced too, simplifying the processing of data to easily identify threats or potential vulnerabilities in the security makeup.

Reaching Beyond Human Capability

The future will be made up of connected intelligent systems that span the intelligent edge, all the way to the cloud. The expectations of these systems are based on the lifecycle of a typical mobile application with constant feature enhancements. But, how do you know what to deliver next, especially when things are moving so quickly, and as developers are inundated with information and data from a number of different sources? This data deluge can be powerful, but it can also be overwhelming.

Crucially, this is where the power of AI and ML comes into play. AI and ML will aid developers in making sense of the information housed across various data warehouses. In DevSecOps, there has always been an approach to automate everything, and AI and ML will be instrumental in automating the analysis and processing of data – a task that is now far beyond the capabilities of humans.

Incorporating AI and ML will enable developers to better understand and use the data at hand. This will see developers understand not only the error, or the occurrence of a fault, but the detail of what happened in the run up to the fault – vastly reducing the chances of incurring that fault again. AI and ML will also be responsible for enabling the transformation from diagnostics to prognostics across any and all tools and systems, making it easier for developers to anticipate, identify and resolve faults or errors.

Increasingly, we’ll see organizations benefit and drive value from real-time insights. They’ll do this through AI and ML frameworks deployed on active systems to deliver optimizations based on real-time development, validation and operational data. This level of real-time actionable insight bolsters DevSecOps’ ability to achieve CI and CD, through improved, reduced mean time to resolution, easing the impact on operations and, ultimately, enhancing the end-user experience. It remains to be seen if incorporating AI and ML into the DevSecOps cycle will achieve the delivery of self-healing systems that can detect and resolve issues without the need for human intervention. With true AI, however, this might well be possible.

The benefits and potential use cases of AI and ML are widely acclaimed, and while we are still some way from seeing their full potential, the capabilities they currently possess are revolutionizing many sectors. The fact is, if DevSecOps is to continue to keep pace with the vastly growing digital data economy, then it will become reliant on advanced technologies such as AI and ML. Data is powerful if used correctly, but with so much of it to process and analyze, that can be a challenge.

A move toward secure automated processes is the progressive step that many organizations need to consider if they are to realize their digital transformation ambitions. Organizations cannot continue to do things the traditional way and expect to get the results that the new world is looking for.

June 3, 2020
Who’s Responsible for Security? Apparently, It Depends

More than 10 years after organizations began implementing DevOps, responsibility for security still resembles the proverbial chicken and egg dilemma.

GitLab’s 2020 Global DevSecOps Survey asked developers, security team members, operations pros and testers about sole responsibility for security in their organizations.

About 28% of developers, 33% of security teams, 21% of ops pros and 23% of testers said responsibility for security rested only on their shoulders. At the same time, 29% of security teams said everyone was responsible, nearly as many as said they had sole ownership.

Confused yet? So were many of our survey respondents, who had a lot to say about the fluid – and frustrating – nature of DevSecOps.

“The team is trusted to do its own security research and implementation. We don’t know how good or bad we are.”

“I am the only one who actually cares about security in my organization.”

“I regularly put security suggestions in the box of suggestions, only to be ignored.’”

“There’s a security team, but it doesn’t involve face to face with us, the dev team. So we just run the dev process without counting on them.”

The Blame Game

There’s a long history of developers and security pros not seeing eye to eye. In GitLab’s 2019 Developer Survey security pros were very expressive on the subject of developers simply not doing enough to enable security. Developers were equally unhappy, citing security’s “heavy-handed approach.”

This year, we drilled down further to see if we could understand why dev and sec continue to see the world differently.

Differences between the teams quickly became apparent. According to the survey findings, 65% of security team members told us their organizations have shifted security left. But the devil is in the details, and the details do not really support a shift left.

A solid majority of developers are not running SAST, DAST or container scans, and only about half conduct compliance scans. Even if the scans are run, less than 19% put SAST results into a pipeline report a developer can access. Dynamic application security testing (DAST) fares even worse – less than 14% of companies gave developers access to those reports.

So, developers don’t have easy access to critical data. On the other hand, security pros are frustrated that developers continue to either miss bugs altogether or find them too late in the process. Over half of security respondents (61%) agreed at some level that vulnerabilities were mostly found by security pros (not developers) after code is merged in a test environment (which is relatively late in the process). In other words, when asked how developers find bugs versus security teams, 93% gave developers credit for discovering only 25% or less of the bugs to be found in existing code, leaving three-quarters of the bugs for security to find at a later stage in the process.

And as if that wasn’t sufficiently frustrating, 69% of security team members complained it was difficult to get developers to remediate bugs, even if their organizations included security as a developer performance metric.

How DevSecOps Can Work

Clearly, there is work to be done to get developers and security on the same page, but we are seeing a few glimmers of hope. Security pros are not quite the lone wolves they once were; many told us that DevSecOps has brought a welcome change to their responsibilities. Nearly 28% reported being part of a cross-functional team focused on security and almost the same number (27%) said they were more hands-on and involved in the day-to-day development activities. Almost 23% said they were now focused more on compliance and about 20% said they did not see any changes in their roles.

In perhaps the most significant (and promising) finding, GitLab asked what skills would be most important to a security professional’s future, the majority (almost 28%) said soft skills like communication and collaboration. Interestingly enough, a majority of their developer counterparts agreed with that.

So, while no one agrees just yet on who owns security or even how to prioritize security, it’s encouraging that both developers and security pros realize they need to prioritize communication and collaboration.

At least one respondent reports success in figuring it all out:

“We don’t have separate security, developers and operations; we are DevSecOps (and more).”

June 2, 2020
Not All Heroes Wear Capes: Celebrating the Tech Community
During these crazy times, I can’t help but wonder, how would I even survive being on lockdown for so long if it wasn’t for technology? It is the one thing that has kept most of us sane while stuck inside during this crisis.

Apps like Instacart and Zoom have been a hit during the pandemic. Why leave the house to go grocery shopping and risk exposure to the virus when you can get your groceries delivered at your doorstep? And thanks to video conferencing services like Zoom, you can have face-to-face meetings with your boss and colleagues, or socialize with your friends and family during happy hour.

Of course, it doesn’t stop there. Tech companies, such as Google and Facebook, have done a great job in providing information on COVID-19 from trusted sources, tips on how to take care of yourself and ways to deal with staying home.

Let’s not forget all the entertaining dance moves we have learned from apps like TikTok, and all the nights we’ve spent binge watching our favorite shows on Netflix. According to Netflix’s quarterly earnings report, the streaming service gained more than 15 million subscribers between January and March.

Technology has helped businesses to carry on working and it has helped all of us to stay strong during these hard and uncertain times.

To celebrate the tech community, MediaOps is hosting the first-ever TechStrong Con, a virtual event that brings together some of the most prestigious industry leaders from companies including Microsoft, JFrog, Red Hat, IBM, GitLab and many more for 12 hours of immersive learning and networking.

Taking place on June 4, starting at 9 a.m. EDT, the event will feature a wide range of tech-related topics, from hardware and applications to processes and business of tech. The sessions are divided into three tracks: Emerging Technologies, Security/DevSecOps and Digital Transformation.

Become a part of the event, get downloadable resources and interact with tech leaders and other attendees. Registrants will also be able to participate in TechStrong raffles for a chance to win one of the following prizes:
- An Xbox One X 1TB Console – Star Wars Jedi: Fallen Order Bundle
- One set of Bose 700 Noise Cancelling Wireless Bluetooth Headphones
- One pair of Apple AirPods Pro
- 10 Amazon gift cards (valued at $50 each)
Strengthen your skills, improve your best practices, empower your teams and become stronger than yesterday. Together we are strong, together we are TechStrong!
May 27, 2020