staging-devopsy.kinsta.cloud

Tag: devsecops

  • How to Make DevSecOps a Reality

    How to Make DevSecOps a Reality

    DevSecOps is an increasingly popular term; however, security vulnerabilities in software continue to proliferate. 2019 saw a surge in web application breaches shining a spotlight on the fact that DevSecOps remains elusive. The latest data from the Verizon Data Breach Investigations Report (DBIR) identified that web application vulnerabilities had doubled in the last year alone.

    With the rapid pivot to all things digital in 2020, the pressure on software and applications continues to intensify. Security needs to be a fundamental part of software development in our digitally dependent world. This requires organizations to focus on more than the speed of delivery and turn their attention to the quality of software as they try to accelerate the pace of digital transformation.

    Achieving DevSecOps

    Organizations striving to achieve DevSecOps need to adopt the following steps to embed security throughout the entire software development life cycle (SDLC).

    Make Security a Priority From Day One

    Security can’t be a bolt-on at the end of the SDLC if your goal is to make DevSecOps a reality. The recent Zoom failures put security flaws in the spotlight and showcased the risks resulting from delivering innovative services without factoring in security. Every member of the team spanning product developers to technical architects to scrum specialists must consider security for it to be an intrinsic part of each stage of development.

    Achieving this transformation to DevSecOps means rethinking how to determine success. Many organizations measure it solely in terms of velocity of time to market without evaluating software quality. Developers remain reticent to incorporate security and turn attention to the quality of code. As a result, software is released more rapidly but with scant regard for the quality, resulting in many applications not being ready for mass adoption.

    One Size Doesn’t Fit All With Security

    Don’t make the mistake of approaching security as a monolith. Instead, accept that it’s wide-ranging, incorporating multiple different areas spanning authentication to access control to confidentiality to integrity to non-repudiation, to name a few. Based on this broad scope, a single approach can’t hope to address all the different facets of security.

    Teams need to rethink security and look at what it means to them and what is essential to their users. This could be keeping customers’ personal identifying information confidential and establishing the types of attacks that are most likely to occur. For example, if your product is inside a corporate file, then compromised credentials and password attacks are a significant risk while denial-of-service attacks are unlikely.

    Every member of the team needs to understand security threats and techniques, so they have enough knowledge to deal with recurring issues. Threat models can include an employee unwittingly doing something wrong to trying to protect data from government-sponsored cybercrime professionals. Focusing your training on these areas will help address the vast majority of problems and ensure applications are secure. It’s vital to view security as a science rather that than an art.

    Don’t Overcomplicate Security

    Security is viewed by many as a problem that can only be solved by highly skilled and paid consultants who specialize solely in security. While there is an absolute need for these skills when reviewing architectures and carrying out audits, there is no requirement for this level of expertise when it comes to basic security checks, such as ensuring that the latest release hasn’t changed the authentication mechanism.

    The vast majority of threat models are solved using standard static and dynamic analysis tools. Once this is accepted, you can resolve 90% of security issues through a combination of tools testers and developers. This enables security to infuse every part of the development life cycle and puts an end to the practice of being an afterthought.

    Conclusion

    Once organizations incorporate these three steps in implementing DevSecOps, they can ensure that achieving security becomes a core component of software delivery. Failure to do so will see that it remains an afterthought and security vulnerabilities will continue to grow.

  • RunSafe Allies With JFrog to Secure Applications

    RunSafe Allies With JFrog to Secure Applications

    RunSafe Security, a provider of Alkemist tools that prevent memory exploits, has partnered with JFrog to create a plug-in for the Artifactory repository manager platform.

    Alkemist employs a combination of runtime application self-protection (RASP) and moving target defense (MTD) methods to neutralize memory corruption exploits such involving, for example, a memory overflow.

    Based on a research project for the Advanced Research Projects Agency of the Department of Defense (DARPA), the integration with Artifactory will make it easier to harden binaries and containers against memory corruption attacks before applications are deployed in a production environment, said RunSafe CEO Joe Saunders.

    RASP describes a class of application security tools that detect attacks in real-time as an application is running. MTD refers to a strategy that relies on changing the attack surface regularly for applications to make it more difficult for cybercriminals to target them.

    Cyberattacks that employ memory exploits attempt to either replace executables with malicious code or overwrite data in a way that changes application behavior. When aimed at operating systems, these attacks commandeer entire systems. They have also been used to launch self-replicating Worm attacks that both cripple systems and insert malware to steal data, corrupting files or installing a back door that enables remote access.

    Saunders said the Alkemist plugin will enable developers to defend applications from these types of attacks without slowing down the pace of application development. Friction is removed from the DevOps process because as code moves through the DevOps workflow, Alkemist automatically hardens it to prevent memory exploits, he said.

    With the growing popularity of containers, Saunders noted that as cybercriminals begin to target them the need to protect containerized applications from memory exploits using best DevSecOps processes will become even more pronounced than it is today.

    While there is clearly a lot of interest in DevSecOps, most developers still don’t have access to the tools needed to better secure applications. As more cybersecurity plug-ins become available for repositories such as Artifactory, the easier it will become to embrace best DevSecOps practices.

    JFrog, for its part, has been making a case for focusing DevOps teams on managing binaries rather than source code. The alliance with RunSafe extends that strategy into the realm of application security.

    It may be a while before DevSecOps practices are widely employed. However, increasingly the issue is becoming less about the tools that might be available. Rather, the cultural challenges associated with implementing cybersecurity gates within a DevOps pipeline is now the major challenge. DevOps teams will need to reconstruct existing DevOps workflows to incorporate cybersecurity gates before an application is deployed. Once that’s accomplished, monitoring applications for anomalies will then need to be incorporated into observability platforms.

    It’s not clear what role cybersecurity professionals will play in this new world of DevSecOps. The one thing that everyone can agree on, however, is the less involved cybersecurity professionals are in the application development and deployment process, the easier it should become to deploy applications that are truly secure.

  • Traceable Secures Apps Using Distributed Tracing

    Traceable Secures Apps Using Distributed Tracing

    Traceable this week announced it is making available under an early access program a namesake platform that combines distributed tracing and machine learning algorithms to better secure applications.

    Fresh of raising $20 million in funding, Traceable CEO Jyoti Bansal said the goal is to leverage distributed traces generated via open source Hypertrace agent software to capture streaming data to which machine learning algorithms can be applied to better secure microservices.

    Bansal, who is also the founder and former CEO of AppDynamics, said this approach leverages software engineering techniques and principles to address application security issues both before and after an application is deployed.

    As part of this effort, Traceable has developed TraceAI, a machine learning engine that has been trained to identify application security issues.

    Once those issues are discovered, developers will be able to apply policies to remediate vulnerabilities using Hypertrace agent software, he said.

    In effect, Traceable is applying many of the principles of application performance management (APM) platforms to securing applications. However, rather than simply aggregating and analyzing data, Traceable has added a streaming engine to collect massive amounts of cybersecurity data in real-time that is analyzed by machine learning algorithms to determine, for example, when and how data might be exfiltrated via an application programming interface (API).

    As the number of microservices that are deployed in enterprise IT environments increases, the number of API endpoints that can be compromised does as well. By adding open source Hypertrace agent software to microservices, Bansal said it becomes possible to leverage distributed tracing to better understand the context in which how business logic embedded within a microservice is being compromised. That context also serves to enable development teams to remediate that issue by either updating or replacing a microservice.

    While the rise of best DevSecOps practices has increased collaboration among developers and cybersecurity teams, Bansal said application security remains largely a software engineering challenge. Application development teams need to find a way to instrument agents to address application security issues within their code instead of relying on overlays deployed by network engineers, he said.

    Most cybersecurity professionals would nod their heads in agreement with that principle. However, it may take cybersecurity teams some time to get used to the idea that they might not need to be as involved with application security as they are today. In fact, the amount of time spent looking for the root cause of any vulnerability is likely to be substantially reduced.

    In the meantime, it’s apparent a primordial soup of agent software, distributed traces, machine learning algorithms and streaming data engines is coming together in a way that will transform application security. It may be a little while longer before the catalyst that converts all those elements into a widely employed platform arrives. However, it appears it’s now more a question of when rather than if there will be a major advance in application security that could take DevSecOps processes to a much higher level.

  • How to Source Vulnerability Data for True DevSecOps

    How to Source Vulnerability Data for True DevSecOps

    Open source comes with code vulnerabilities that must be considered in the DevOps process

    The war between open source and “only proprietary code” is long over. Open source won the day by convincing the opposition of the benefits of joining the open source community. “Vulnerabilities in the Core,” a report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020, explained: “Open source has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smart phones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”

    Development teams have embraced open source for its inherent strengths: efficiency, speed, quality and innovation. As one Gartner report puts it, “In most modern DevOps development projects, the majority of code used in an application is made up of open source.”

    But open source comes with code management responsibilities that DevOps teams need to consider. Open source has the same security risks that plague all software—bugs or other defects that could be exploited by hackers. While larger open source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors, thanks to thousands of “eyes” on the code, keeping open source software secure is not as simple as enabling auto-updates, as is done for much commercial software.

    Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open source component first need to be aware that the patch is out there and then “pull” it from a repository to accomplish the needed update.

    The NVD and Its Timeliness Problem

    Public sources such as the National Vulnerability Database (NVD) are a good first step for information on publicly disclosed vulnerabilities in open source software. However, you need to keep in mind that there can be significant lags in data reporting, scoring and actionability of the data in an NVD common vulnerabilities and exposures (CVE) entry, with some research reporting an average 27 days between the initial announcement and NVD publication. The format of NVD records also makes it difficult to determine which versions of any given open source component are affected by a vulnerability.

    For example, the Linux vulnerability CVE-2016-5195, popularly known as Dirty Cow, was announced Oct. 19, 2016. Proof-of-concept code exploiting the vulnerability was available a full two weeks before the Nov. 10 listing for the CVE in the National Vulnerability Database. That’s two weeks in which anyone relying on the NVD would have been left in the cold.

    The problem is more recently reflected in the findings of the 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC). Four of the top 10 vulnerabilities found in the audited codebases did not have CVEs associated with them at the time of the report’s publication. The vulnerabilities without CVEs included high-severity flaws in jQuery and FileAPI. Those security issues can be fixed with updates of the respective open source components, as can the majority of vulnerabilities listed in the CyRC OSSRA report. But, to patch any of those CVE-less vulnerabilities, you first need to be aware of them.

    The issues impacting the NVD’s ability to publicize security vulnerabilities make it unwise to rely solely on that organization for vulnerability information. While I’m not recommending abandoning the NVD, DevOps teams should look to a secondary source of information that will provide better notification of vulnerabilities affecting your codebase and, ideally, supplement notifications with technical details and upgrade and patch guidance.

    Augmenting NVD Vulnerability Information

    Many commercial software composition analysis (SCA) solutions can provide you with more timely, richer vulnerability data than the NVD alone, proactively finding issues and helping you fix them quickly when warranted. If you’re considering an SCA solution, you should ask your vendor what they offer in the form of security advisories and alerts.

    For example, consider the Common Vulnerability Scoring System (CVSS), an industry standard for assessing the severity of a vulnerability. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

    A robust SCA solution will provide a temporal score in addition to the CVSS base, exploitability and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

    Similarly, an SCA solution should offer key Common Weakness Enumeration (CWE) classifications—a list of software or hardware weaknesses that have security ramifications—for all vulnerabilities, providing insight into the type of weakness being exposed. A CWE classification tells developers which type of weakness leads to the vulnerability in question.

    Information such as this can help you understand what you’re dealing with and aids in assessing the severity of the vulnerability for mitigation purposes. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.

  • ShiftLeft Brings Security Workflows to DevOps Processes

    ShiftLeft Brings Security Workflows to DevOps Processes

    ShiftLeft has updated its NextGen Static Analysis (NG SAST) tool to include workflows that are purpose-built for developers.

    Company CEO Manish Gupta said the security workflows are designed to make it easier for DevOps teams to incorporate them within their application development and deployment processes. In fact, a survey of more than 165 developers, application security and DevOps professionals conducted by ShiftLeft finds 89% of respondents said the current disconnect between developers and cybersecurity teams is the biggest inhibitor of productivity.

    The issue with rival static analysis tools is they were not designed from the ground up to incorporated into a DevOps process, said Gupta. As a result, he noted, security workflows are managed around application development processes rather than being incorporated within them.

    The survey finds that most IT teams are performing security scans too late in the software development life cycle (90%) and when they do discover an issue they often lack any remediation guidance (88%).

    Most existing cybersecurity processes can’t keep pace with the rate at which applications are being deployed. The survey finds nearly 70% of software development organizations are releasing multiple times per month or more, with 18% releasing at least daily.

    Gupta said NG SAST overcomes that issue by automating code analysis during every pull/merge request. That approach enables developers to address security issues much the same way they do any other bug. Rather than having to wait on a report from an application security team, developers can remediate a security issue from within their development environment log before it ever shows up in a report, he said.

    Productivity and application quality improves because vulnerabilities get fixed faster while the code at issues is still uppermost in the mind of the developer, Gupta said.

    DevOps teams can also create build rules that accept or deny merges based on how many security vulnerabilities there are, he added. That capability prevents security flaws from become too deeply embedded within the build process before they can be more easily remediated.

    Gupta said security scans are also run locally where applications are deployed, which means source code never has to leave the organization. That approach also eliminates the need for network and firewall architecture updates to access an external scanning service. It also reduces bottlenecks inside organizations that might need to do as many as 20 scans per hour, he noted.

    Overall, Gupta said it’s not uncommon to see developer productivity increase by a factor of 40 because ShiftLeft NG SAST enables scans to be run instantly. The days when developers took a coffee break while waiting for a security scan to run are now over, he said.

    Of course, the level of productivity gain for development teams that might be gained by embedding static analysis within the application development process will vary widely. However, given the fact that developers outnumber cybersecurity professionals by several orders of magnitude, it’s also readily apparent dedicated application security teams can’t keep up. Unless organizations give developers the security tools they need, any ambitions an organization may have about implementing best DevSecOps processes will remain largely a pipe dream.

  • Snyk Report Finds Decline in Open Source Vulnerabilities

    Snyk Report Finds Decline in Open Source Vulnerabilities

    Snyk, a provider of tools for discovering and remediating vulnerabilities in open source code, today published a report that finds the number of new vulnerabilities discovered in open source software packages has declined 20% on a year-over-year basis. However, the bulk of the vulnerabilities being discovered are considered to be high severity, the report finds.

    Alyssa Miller, application security advocate for Snyk, said the decline represents a significant improvement as developers become more conscious of cybersecurity issues. As long as humans write code there will always be security issues; however, Miller said the latest report suggests improvements in open source security are likely to continue as more developers embed vulnerability scanning tools within their application development tools.

    Those tools enable developers to discover vulnerabilities in their code long before they ever find their way into a production environment, she noted.

    The Snyk report is based on a survey of 500 developers, security practitioners and IT operations staff and scans run by Snyk on open source software packages. It finds the top vulnerability currently impacting scanned projects is prototype pollution, which results in objects in JavaScript applications being modified, was found in nearly 27% of all the projects Snyk surveyed.

    Better-known vulnerabilities, such as cross-site scripting attacks, are still being reported in high numbers, but Snyk reported the number of projects actually being impacted by this class of vulnerabilities is fairly low. These threats appear to be getting caught and remediated much earlier than many lesser-known vulnerabilities, said Miller.

    Want to learn more? Tune in Tuesday, June 30, at 11 a.m. Eastern for The State of Open Source Security in DevSecOps Pipelines: A Panel Discussion, a staging-devopsy.kinsta.cloud webinar hosted by Snyk

    The report notes the bulk of the vulnerabilities discovered continue to involve indirect dependencies (70%) within packages built using tools such as Node Package Manager (86%), Ruby (81%) and Java (74%). The survey also finds 60% of organizations do not fully inventory the dependency trees in their software.

    Despite the progress being made, Miller said it’s clear much work needs to be done. For example, the survey finds more than 30% do not review Kubernetes manifests for insecure configurations. Requirements for security-related resource controls in Kubernetes are also not widely implemented, according to the survey. Many container images labeled as final contain large numbers of known vulnerabilities—the 14.3 Node image had 642 known vulnerabilities, for example.

    In addition, 44% of the participants indicated that they are currently using Kubernetes to orchestrate their containers. Many respondents who said they use Kubernetes also employ Helm to package applications (40%). According to the report, 68% of stable Helm Charts contain an image with a high severity vulnerability.

    Ironically, Miller noted many of the same vulnerability issues that have derailed many “golden image” initiatives in the past decade appear to be manifesting themselves again in the age of containers.

    Finally, the survey finds 57% of respondents have implemented static code analysis tools (SAST), followed by employing security test cases during quality assurance (28%); dynamic application security testing (DAST) (20%); software composition analysis (19%); and threat modeling (19%).

    Despite that relatively low reliance on security tools in the development process, it’s clear progress is being made as DevOps teams and cybersecurity teams collaborate more closely. As more security tools are incorporated into the DevOps pipeline, application security should begin to improve at even faster rates.

  • SaltStack Looks to Automate DevSecOps Processes

    SaltStack Looks to Automate DevSecOps Processes

    SaltStack announced today it has integrated its automation framework with a variety of third-party security platforms to further the adoption of best DevSecOps processes.

    Mehul Revankar, director of product management for SaltStack, said version 6.3 of SaltStack Enterprise provides integration with offerings from Splunk, Tenable, Qualys, Rapid7 and Kenna Security. Data generated from vulnerability scans conducted using tools from Tenable, Qualys and Rapid7 can be directly imported into SaltStack Enterprise to inform automated DevSecOps processes, while integration with Kenna Security makes it easier to automate and prioritize vulnerability remediation based on the level of risk.

    Revankar said that latter capability is crucial because remediation efforts should not be prioritized based on the severity of a vulnerability alone. For example, a vulnerability may be discovered in an application that sits behind a firewall, but if that application doesn’t provide access to the web an organization may decide to not patch that vulnerability immediately regardless of its severity because the risk of a breach is still relatively low, he said.

    These capabilities will enable SaltStack Enterprise to serve as a foundation for providing security orchestration, automation and response (SOAR) capabilities within the context of a DevSecOps process by making it easier to incorporate cybersecurity within the context of a larger playbook for automating the management of IT, he added.

    Most of those playbooks will be developed by DevOps teams in collaboration with cybersecurity professionals, noted Revankar.

    In addition to improving DevSecOps processes, SaltStack hopes to make it easier for external applications such as Splunk and Datadog to consume data generated by its framework by providing compatibility with Prometheus, an open source IT monitoring tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). A SaltStack Enterprise Splunk add-on tool has been added to the Splunkbase repository.

    SaltStack is also making available a performance and health dashboard to enable DevOps teams to track 25 SaltStack Enterprise metrics that are surfaced using the Prometheus data format.

    The open source Salt framework on which SaltStack Enterprise is based has emerged as a popular option for automating IT processes. Because it is based on Python, the barrier to adoption for Salt in terms of programming expertise is comparatively low to other programming languages. As such, more IT operations teams have been inclined to learn Python to leverage Salt to automate processes.

    Like most vendors that have adopted open source business model, SaltStack extends the capabilities of Salt via an enterprise edition that it both extends and provides commercial support.

    Interest in IT automation is on the rise as organizations of all sizes look to maximize what limited cybersecurity resources they have and cut costs. IT automation in the form of SOAR presents an opportunity to consistently apply cybersecurity policies more broadly without having to increase the size of the IT organization.

    The challenge, of course, is having the expertise required to build a playbook. In the case of open source frameworks, many of those playbooks are shared among the members of a community such as Salt. Regardless of how those playbooks are acquired, it’s clear that as IT becomes increasingly more complex most IT organizations are not going to be to do without them.

  • The Secret to Winning at DevOps: Are You Up for the Challenge?

    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.

  • Participate in the Checkmarx 2020 Survey

    Participate in the Checkmarx 2020 Survey

    Checkmarx, the global leader in software security solutions for modern enterprise software development, and staging-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!

  • What Developers Really Think About Pentesting

    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.