staging-devopsy.kinsta.cloud

Tag: devsecops

  • Why DevOps and Federal Agencies Need Each Other

    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.

  • GitLab Adds Fuzz Testing to DevSecOps Toolbox

    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.

  • 3 DevOps Security Best Practices Your Organization Can’t Afford To Ignore

    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.

  • DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    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.

  • How DevOps Powered by AI and Machine Learning Is Delivering Business Transformation

    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.

  • Who’s Responsible for Security? Apparently, It Depends

    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).”

  • Not All Heroes Wear Capes: Celebrating the Tech Community

    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!

  • GitLab Releases Massive Update to CI/CD Platform

    GitLab Releases Massive Update to CI/CD Platform

    GitLab has updated its continuous integration/continuous delivery (CI/CD) platform with a raft of capabilities spanning everything from value stream management to cybersecurity.

    In addition, GitLab announced it is making generally available Gitaly Clusters, which enable DevOps teams to create a warm replica of a Git repository.

    Brendan O’Leary, senior developer evangelist at GitLab, said with release 13 GitLab continues to build on a single code base that allows the platform to be managed and accessed as an integrated set of applications rather than disparate components that DevOps teams need to pull together and then manage.

    In terms of core DevOps capabilities, the latest release adds the ability to customize the Value Stream Analytics module to specific workflows. GitLab is also planning to make it possible to visualize stages of a workflow.

    GitLab is also improving traceability between requirements and has added the ability to visualize the workflow associated with a specific release. A future release will enable DevOps teams to employ feature flags to conduct both A/B testing based as well as create feature flags from merge requests and to filter feature flags by status, according to the company.

    Other capabilities added include more customizable dashboards, with security dashboards now being shareable outside of GitLab to foster collaboration with IT security teams. Future releases will add Kubernetes Clusters to the dashboard to show all clusters and pods in use.

    DevOps teams now can route existing monitoring alerts to GitLab for triage and incident resolution. At the same time, GitLab has moved design management to the core platform.

    GitLab is also now making AutoDevOps, which provides pre-defined CI/CD pipelines, available on Amazon Web Services (AWS).

    In terms of cybersecurity, GitLab has revamped the way the platform manages vulnerabilities to make it easier in a future update to prioritize remediation efforts.

    GitLab also has static application security testing (SAST) support for .NET frameworks and has expanded support for offline environments. There’s also now support for dynamic application security testing (DAST) for REST application programming interfaces (APIs) and access to full commit history scan for secrets. Fuzz testing support will be introduced later this year, according to the company, along with an ability to secure secrets across services. GitLab also plans to add integration with security tools that track container behavior analytics, as well as an out-of-the-box container network policy.

    Thanks to GitLab’s collaboration with Okta, there is now also tighter integration with Okta’s System for Cross-domain Identity Management, which can be provisioned for a GitLab group.

    In terms of compliance, GitLab also plans to enable DevOps teams to establish a compliance framework, adopt its regulatory controls and simplify audit reporting. The company is also working on an initial security policy user interface to simplify setting up security guardrails.

    Finally, GitLab has become a Common Vulnerabilities and Exposures (CVE) ID Numbering Authority (CNA). GitLab users can request a CVE from GitLab, either for GitLab itself or for any project hosted on GitLab.com. In the future, users can request CVE IDs directly from within GitLab.

    O’Leary said GitLab is working toward increasing developer confidence in their security skills. By making it easier to embrace best DevOps practices, developers no longer will have to tiptoe around security issues that they today largely have little to no familiarity with, he said.

    In general, O’Leary said GitLab’s biggest challenge is getting organizations to move beyond simply using it to manage source code. Once organizations do make their first foray beyond source code management, however, it’s not too long before they are employing a wide range of modules, he noted.

    Of course, encouraging organizations to dive deeper DevOps has as much to do with the culture of the organization as it does the capabilities of the CI/CD platform employed.

  • The Best Approach to Help Developers Build Security into the Pipeline

    The Best Approach to Help Developers Build Security into the Pipeline

    Speed and agility are at the core of digital transformation and DevOps culture, and have quickly become a business imperative for organizations that want to remain competitive. Speed cannot come at the sacrifice of security, though. The pace of software development requires that security be baked into the code from the start rather than tacked on after the fact. Developing secure code fast requires empowering developers with the skills and tools they need and building security into the DevOps pipeline.

    Embracing DevSecOps

    DevOps culture and the drive to work faster and more efficiently affects everyone in the organization. When it comes to creating software and applications, though, the responsibility for cranking out code and producing quality code falls on developers.

    The pace of DevOps culture doesn’t allow for anything to be an afterthought. It’s important for developers to support security directly as a function of application development in the first place, and to operationalize security within the continuous integration/continuous deployment (CI/CD) pipeline.

    Unfortunately, traditional education does little to prepare them. It’s possible to get a PhD in computer science and never learn the things you need to know to develop secure code. As organizations embrace DevSecOps and integrate security in the development pipeline, it’s important to ensure developers have the skills necessary. You also need to focus on both the “why” and the “how” in order to build a successful DevSecOps training program.

    Don’t Just Check the Box

    Not all training is created equal. Consider why you’re doing the training and the outcome you hope to achieve rather than doing training for the sake of training. Many organizations focus on training developers in secure coding practices from the perspective of compliance. It’s crucial to engage developers in a meaningful way, though, and not just check a box.

    Many compliance frameworks, such as PCI-DSS, require ongoing application security training, but compliance training often reinforces the wrong lessons. Developers learn the most expedient way to check the box and achieve compliance rather than learning the most efficient way to develop secure code. This approach also causes developers to feel like the security team looks down on them or doesn’t understand the challenges they face or the expectations they have to meet.

    The Carrot and the Stick

    How you do security is also important. Training works better when developers feel like they are part of the process and when they have a reason to want to excel.

    For nearly everyone, doing something in practice reinforces lessons better than just reading content or listening to a webinar or video. Interactive labs are more engaging and provide feedback as developers go through the training. They can practice writing secure code with guided practice that is self-paced. They can also get hands-on experience exploiting vulnerable applications, then patching them back up.

    You should implement developer training that creates incentives for developers by gamifying training. Create custom Capture the Flag events, track individual progress and provide a leaderboard that enables healthy competition among the developers.

    You also want to provide developer training that is relevant to your organization’s preferred coding languages and business objectives. The training should teach skills and strategies that are applicable to the code your developers work with and give them tools they can use immediately to improve the security of the applications they’re working on.

    Speed is essential for businesses to maintain a competitive edge today, and security is more important than ever. Make sure you have the training in place to help shift application security knowledge left and integrate security to mature DevSecOps practices.

  • GitLab Survey Sees DevOps Gains as Developers Exercise More Control

    GitLab Survey Sees DevOps Gains as Developers Exercise More Control

    A global survey of 3,650 software professionals published by GitLab respondents indicates developers are exercising more direct control over IT environments.

    More than a third of respondents (35%) said developers define and/or create the infrastructure their applications run on, with 14% actually monitoring and responding to infrastructure events. Additionally, 18% of developers instrument code for production monitoring, while 12% serve as an escalation point when there are incidents.

    More than 25% of developers reported feeling solely responsible for security, while 33% of security team members say they own security. A total of 29% said they believe everyone should be responsible for security.

    A quarter of respondents said their organizations have been practicing DevOps for three to five years, while 37% said they have been practicing for one to three years. Nearly 60% of respondents said their organizations deploy code either multiple times a day, once a day or once every few days, a 15% increase over the previous year.

    Brendan O’Leary, senior developer evangelist for GitLab, said that massive jump in the number of organizations capable of deploying code at faster rates indicates many more organizations are starting to move further along the DevOps maturity curve. For example, the survey finds 70% of developers can now provision their own IT environments.

    Well over a third of respondents (38%) said their DevOps implementations include a continuous integration/continuous delivery (CI/CD) platform. Almost 59% of those surveyed use GitLab, while 23% use GitHub and 11% use BitBucket. For builds, 60% use GitLab and 38% use Jenkins. A total of 29% said their DevOps implementations include test automation, while 16% said they have embraced DevSecOps.

    Almost 40% of survey takers said they “partially” use microservices, while a quarter (26%) said they fully use them. Well over a third (38%) have also adopted Kubernetes.

    Despite that progress, however, the survey makes it clear there is still much work to be done. More than 42% said testing still happens too late in the life cycle. In fact, 47% identified testing as the top DevOps bottleneck for the second year in a row. Only 12% said they have completely automated testing.

    When it comes to security, well over a third (36%) find it hard to understand, process and fix any discovered vulnerabilities. About a third (31%) said prioritizing vulnerability remediation is still an uphill battle.

    O’Leary said when it comes to security the most challenging issue remains determining what vulnerabilities to prioritize alongside a long list of other bugs and issues that often need to be addressed. Cybersecurity teams all too often continue to send developers a list of vulnerabilities they have discovered with no context, he noted. Many developers are only made aware of an issue after their code has been merged, which O’Leary said makes it more difficult for them to address a specific security issue.

    It’s not clear any organization will ever achieve complete DevOps nirvana. However, as organizations become more proficient it’s clear the return on investment in DevOps is starting to be achieved as more organizations deliver code faster. The challenge now, of course, is making sure the right secure code is delivered at the right time.