devopsy.kinsta.cloud

Category: News

  • Cycode Expands Scope of AppDev Security Platform

    Cycode Expands Scope of AppDev Security Platform

    At the Black Hat USA 2022 conference, Cycode this week announced it has added static application security testing (SAST) and container scanning capabilities to its software composition analysis (SCA) platform that is based on a graph database.

    Amnon Even-Zohar, director of product management for Cycode, said the addition of these tools brings to eight the total number of modules that are now integrated with its Knowledge Graph database. Those modules address application security requirements spanning everything from infrastructure-as-code misconfigurations and DevOps pipelines to binary and source code analytics in a way that reduces both the number of false positives being surfaced, he added.

    That approach makes it possible to provide more context to software remediation efforts by pulling data from across the entire software development life cycle rather than focusing solely on vulnerabilities found in source code, he noted. Cycode, for example, can pinpoint where vulnerable dependencies are found in test and production environments, said Even-Zohar.

    A Cycode Pipeline Composition Analysis tool also provides insights into which components enable a vulnerability or security issue, how pipeline components relate to each other and if they are present in runtime environments, he added.

    While there’s a lot of interest in implementing DevSecOps best practices in the wake of a series of high-profile AppSec breaches, many organizations still lack the tools required to secure an application development environment on an end-to-end basis. The Cycode platform leverages the data that already exists in DevOps workflows to enable organizations to better prioritize their remediation efforts and lower the total cost of doing so, said Even-Zohar.

    The goal is to not only enable organizations to shift cybersecurity further left toward developers but also further right by more closely integrating cybersecurity and DevOps teams, he noted.

    The DevSecOps challenge that most organizations are trying to navigate is that, historically, a list of vulnerabilities discovered by cybersecurity researchers is shared with DevOps teams without much context. Developers don’t know which vulnerabilities are most critical or, for that matter, whether the vulnerability identified is actually present within their application environment. SCA tools, in theory, could make it easier to identify, for example, where a Log4j or a shell vulnerability might be found. Graph-based tools take that capability to the next level by making it easier to visualize where any instance of a vulnerability might be found. In the absence of such tools, IT organizations would spend weeks looking for each instance of a vulnerability.

    It may be a while before DevSecOps workflows become commonplace but at the very least there is now more awareness of software supply chain security issues. The Biden administration has also issued an executive order that requires federal agencies to review the security of software supply chains. Many enterprise IT organizations are now following suit. One way or another, application security is going to improve. The only thing that remains to be determined is what impact those improvements will have on the rate at which software can be built and deployed.

  • CloudNativeDay: WASM to Drive Next IT Epoch

    CloudNativeDay: WASM to Drive Next IT Epoch

    WebAssembly (WASM) is poised to drive the next era of development of cloud-native applications that can truly run anywhere.

    Liam Randall, CEO of Cosmonic, a provider of a platform for building and deploying WASM applications, told attendees at a virtual CloudNativeDay event that WASM will be at the core of a new IT epoch that will enable organizations to more quickly build highly portable applications that are not tied to any IT infrastructure platform and more secure.

    WASM, at its core, is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The World Wide Web Consortium (W3C) drove the development of WASM as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to create a set of universal binaries that could work on any platform without modification.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries between them. One of the issues of that approach is that it becomes relatively simple for malware to infect all the components of an application.

    The Cloud Native Computing Foundation (CNCF) is now trying to advance the adoption of a Cosmonic’s WASM runtime that makes it possible to run WASM applications on any platform versus being constricted to building applications that can only run, for example, on Windows or Linux.

    That level of portability will prove crucial as more organizations look to drive application deployments on a wide range of edge computing platforms, noted Randall.

    It may be some time before WASM becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are finally starting to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. That’s not only critical in terms of overall application developer productivity, it has major implications in terms of streamlining the management of DevOps workflows as it becomes easier to both initially deploy applications and continuously update them.

    In the meantime, as organizations continue to review their application development practices to better secure software supply chains, it’s become clearer that legacy approaches to building applications are fundamentally flawed. Rather than attempting to reengineer processes to encourage developers to better secure applications, it may be more effective to change the way applications are built. After all, considering all the processes required to secure legacy approaches to application development, it may be cheaper and easier to adopt a new app development method.

    The challenge, of course, is, as always, taking that first initial step away from the inertia of legacy application development approaches.

  • GitHub Brings 2FA to JavaScript Package Manager

    GitHub Brings 2FA to JavaScript Package Manager

    GitHub has made generally available a two-factor authentication tool for the package manager for JavaScript applications maintained by its NPM, Inc. arm.

    In addition, all npm packages have been re-signed and there is now an npm command line interface (CLI) command to audit package integrity.

    Finally, GitHub has added the ability to connect GitHub and Twitter accounts to npm along with a streamlined login and publishing experience with the npm CLI.

    Myles Borins, staff product manager for open source at GitHub, said these enhancements are part of an ongoing effort to enable organizations to better secure their software supply chain by better protecting credentials against being used to take over GitHub accounts.

    There isn’t a huge volume of these types of attacks, but it’s apparent cybercriminals are attempting to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, noted Borins. Once cybercriminals gain access, they could potentially insert malware in software components that could find its way into any number of downstream applications. That malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. More troubling still, that malware might begin to spread laterally across an entire application environment.

    GitHub is currently dealing with the fallout from a report that its repositories were attacked; that turned out to be a false alarm. The repositories attacked turned out to be either forks or clones of real, popular repositories with names similar to legitimate repositories on the GitHub platform. No malicious code was actually merged into any of the original repositories; however, it’s apparent cybercriminals are using a technique known as spoofing commit metadata to attempt to trick developers into committing code to a fake repository.

    The challenge that GitHub is trying to navigate is the degree to which some security controls should be enabled by default based on the level of risk, said Borins. Individual developers, for example, might have a higher tolerance for risk than an enterprise IT organization building an application that is core to the processes that drive the business, he noted. In some cases, organizations may opt to restrict access altogether whenever a user name/password can’t be remembered while others will simply limit access to ensure productivity is maintained, added Borins.

    In general, the average enterprise IT organization is likely to have a higher tolerance for disrupting workflows to make sure critical intellectual property is always protected, he added.

    The critical issue, of course, is no one knows for sure what open source component might one day wind up in what application. Regardless of the type of application, developers now routinely reuse code that could contain any number of known vulnerabilities or zero-day vulnerabilities that have yet to be discovered. The foundation for building secure DevSecOps workflows for most organizations at a bare minimum is going to start with implementing two-factor authentication, said Borins.

    Regardless of the DevSecOps approach, just about everyone recognizes there is a need to better secure software supply chains. The one thing that remains to be determined is what impact achieving that goal might actually have on the rate software is being built and delivered.

  • CREST Defines Quality Verification Standard for AppSec Testing

    CREST Defines Quality Verification Standard for AppSec Testing

    At the Black Hat USA 2022 conference, CREST today shared a quality assurance verification standard to improve application security testing. The standard is based on the open source framework defined by the Open Web Application Security Project (OWASP).

    Tom Brennan, executive director for Americas at CREST, said the OWASP Verification Standard (OVS) measures an organization’s ability to execute and deliver assessments related to Level 1 and Level 2 of the OWASP Application Security Verification Standard (ASVS) and OWASP Mobile Application Security Verification Standard (MASVS).

    The goal is to provide a consistent methodology for accrediting companies that provide application security testing services, said Brennan. Ultimately, organizations of all sizes will then be able to require application software providers to pass an OWASP accreditation test rather than testing the security of every application they use, he noted.

    Organizations need to be accredited through CREST Penetration Testing to apply for the OVS program, which requires companies to demonstrate that they can meet the program requirements and execute and deliver Level 1 and Level 2 ASVS and MASVS services. Level 1 determines whether or not applications store or handle sensitive data; that determination then defines whether or not they need the more rigorous controls of Level 2 or 3. Level 1 controls can be checked either automatically using tools or manually without access to source code. Level 2 ensures that security controls are in place, effective and used within the application. In addition, all organizations will need to ensure that their teams have completed CREST’s Skilled Person Register and have each signed the CREST code of conduct.

    CREST is a nonprofit organization that was originally known as the Council of Registered Ethical Security Testers. CREST works with governments, regulators and multinational organizations to improve application security using CREST OVS Mobile and CREST OVS Apps accredited services. It’s becoming more common for organizations to require OVS to better ensure application security in much the same way they require compliance with frameworks such as the System and Organization Controls (SOC) framework, said Brennan.

    OWASP is administered by a separate nonprofit foundation that works to improve the security of software by sponsoring community-led open-source software projects and training application developers. By aligning with OWASP, CREST creates a verification standard to provide a more structured approach to implementing ASVS and MASVS, noted Brennan.

    OVS, of course, is arriving at a time when there is now a much greater focus on software supply chain security in the wake of a series of high-profile breaches. It is apparent cybercriminals have become more adept at discovering and exploiting a wide range of known software vulnerabilities. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to review the security of their software supply chains.

    It may be a while before application testing using OVS becomes routine, but as more organizations embrace DevSecOps best practices to secure their software supply chain it’s clear there is a greater need for application security testing standards. Especially those that organizations can extend versus reinventing the wheel.

  • IBM Unveils Simulation Tool for Attacking SCM Platforms

    IBM Unveils Simulation Tool for Attacking SCM Platforms

    At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

    Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

    The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

    IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

    It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

    Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

    Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

    It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

  • Recession! DevOps Hiring Freeze | Data Centers Suck (Power) | Intel to ‘be’ Wi-Fi 7

    Recession! DevOps Hiring Freeze | Data Centers Suck (Power) | Intel to ‘be’ Wi-Fi 7

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Engineer jobs are being cut, cloud infrastructure is using too much energy, and Intel’s 802.11be silicon is alive. (more…)

  • Orgs Struggle to Get App Modernization Right

    Orgs Struggle to Get App Modernization Right

    A survey published today found 93% of IT leader respondents admitted that application modernization efforts are either extremely or somewhat challenging.

    The survey, which polled 150 IT leaders at organizations with at least 1,000 employees, was conducted by Asperitas, an IT services provider. The survey found the primary issues respondents identified were identifying the right tools and technologies (30%) followed by finding staff with the right experience (20%), choosing the right external partner (18%), getting users trained on new systems (17%) and securing the support of management (11%).

    More than three-quarters of respondents (78%) said the top priority for organizations taking on application modernization should be “getting it right.”

    The definition of application modernization is, like many things, in the eye of the beholder. One-third of respondents defined modernization as the use of cloud-based infrastructure while 32% said it was moving legacy systems to the cloud. Another 22% defined it as using cloud-based tools.

    More than half of respondents (54%) said employing microservices meant that they were modernizing, while 59% said the use of any cloud-native services indicates as much.

    Scott Wheeler, practice lead at Asperitas, said that while there are a lot of definitions of application modernization, it’s clear that the lift-and-shift era of moving applications to the cloud is coming to an end. Organizations are instead preferring to build and deploy applications using a wide range of cloud-native platforms and platform-as-a-service (PaaS) environments they don’t have to manage.

    The challenge is many of these applications are being built and deployed on multiple clouds. More than a quarter (27%) said the biggest multi-cloud challenge was securing applications, followed closely by integration with on-premises systems and other cloud platforms (26%). Another 20% identified ensuring portability between platforms as the biggest challenge.

    A total of 80% also noted upskilling of internal staff and making improvements to antiquated processes were extremely important to application modernization. In fact, one of the major issues that organizations still need to address is the degree to which “bad DevOps” practices are being applied to modern application environments, said Wheeler. Much of that issue stems from the simple fact that many IT teams still don’t know how to effectively manage cloud computing platforms, he added.

    Well over a third (36%) said that a key application modernization best practice was giving yourself ample time to complete the project while an equal percentage identified avoiding shortcuts, distractions and/or partners that over-promise. Another 34% said the most important lesson was choosing the best tool for the job, while nearly a quarter (24%) identified waiting too long to modernize a system that’s clearly in need of modernization.

    A full 100% of respondents said application modernization was very or somewhat important to their business, with 45% reporting the applications they had chosen to modernize were critical. A little more than a quarter (28%) also noted modernization has enabled them to innovate faster and scale more rapidly, while 25% said it could improve end user productivity and 11% said it might make their company more attractive to employees and customers.

    Regardless of the motivation for modernizing applications, just about every organization is engaged in these efforts to varying degrees. The issue doesn’t seem to be the willingness to start these projects as much as it is making sure they are completed quickly enough to be relevant to the business.

  • GitHub Adds Tools to Simplify Management of Software Development

    GitHub Adds Tools to Simplify Management of Software Development

    GitHub has made generally available Projects powered by GitHub Issues, a set of tools for managing application development projects based on a spreadsheet interface.

    Mario Rodriguez, vice president of product management at GitHub, said these tools enable DevOps teams to more easily filter, sort and group issues and pull requests. That capability makes it possible to, for example, configure and track cycle velocity and current work status and create visualizations using cumulative flow diagrams.

    Over the course of the rest of this year, Rodriguez said GitHub also plans to add additional capabilities including custom triggers, conditionals and action logic along with a mobile edition of Projects powered by GitHub Issues.

    The overall goal is to provide DevOps teams with a set of project management tools that enable organizations to plan where they code, said Rodriguez. In many cases, that approach eliminates the need to deploy a separate set of project management applications, he added.

    As more organizations become dependent on software to drive digital business processes, it’s become apparent that managing all the ongoing application development projects has become a significant challenge. GitHub has been developing Projects powered by GitHub Issues to provide organizations with a set of tools that can be accessed not just by DevOps teams but also by application owners and business leaders to track the status of various projects, said Rodriguez.

    Most organizations have not reached the point where revenue growth is completely dependent on the rate at which software is developed and deployed, he noted. However, as DevOps teams more regularly engage other departments in the business, Projects powered by GitHub Issues can provide anyone with access to a spreadsheet-like application that is simple to use, said Rodriguez.

    In general, GitHub is committed to improving developer experiences at a time when organizations are competing for the best talent available, added Rodriguez. If salary and benefits are equal, the decision to work for one company versus another comes down to the quality of the application development experience, he noted.

    As the provider of the most widely-used code repository, GitHub has been extending the reach and capabilities of its platform to address a range of DevOps workflow issues. The issue that DevOps teams need to address is how to anchor those workflows to a code repository versus the continuous integration/continuous delivery (CI/CD) platforms they employ to build and deploy applications.

    Regardless of approach, there’s no doubt that DevOps teams can now construct more scalable workflows. That’s critical, because the number of concurrent application development initiatives that organizations are managing simultaneously has increased substantially in recent years. The underlying platforms used to manage those projects need to be extensible to prevent workflows from becoming overly rigid, said Rodriguez.

    It’s not clear to what degree business leaders appreciate the value of DevOps workflows, but as business processes continue to evolve, the ability to effectively compete could rest on the agility of an application development team.

  • Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks has added support for GitHub Actions, GitLab Runners, CircleCI and Argo Workflows to Checkov, an open source tool that scans programmatically provisioned infrastructure for misconfigurations.

    Guy Eisenkot, senior director of product at Bridgecrew by Prisma Cloud at Palo Alto Networks, said the goal is to make it easier to secure configurations created using infrastructure-as-code (IaC) tools such as Terraform.

    Those additions are now available as part of a Checkov library of policies, including graph-based checks, that provide a context-aware way of identifying risks within infrastructure and application code within a DevSecOps workflow using a tool that enables IT teams to manage policy-as-code, he noted.

    Misconfigurations of cloud infrastructure have become a major issue. Typically, that infrastructure is programmatically provisioned by developers that have little to no cybersecurity expertise. As a result, cybercriminals are now more aggressively scanning for misconfigurations that they can exploit to, for example, exfiltrate data or illicitly access services via application programming interfaces (APIs). Checkov makes it easier to identify those potential security issues within the context of a DevOps workflow before cloud infrastructure is provisioned, noted Eisenkot.

    There is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. The Biden administration last year even went so far as to issue an executive order requiring federal agencies to review the security of their software supply chains. The challenge is that most organizations have yet to implement a truly developer-centric approach to ensuring application security, said Eisenkot.

    In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications today are clearly problematic. A chronic shortage of cybersecurity staff further aggravates the issue, because most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    As more organizations are also starting to embrace DevSecOps best practices, the overall state of cybersecurity should improve. The challenge is that no matter how much time and effort is made to educate developers, there will always be mistakes a cybercriminal can exploit. Policy-as-code tools like Chekhov make it much less likely those mistakes will carry over into a production environment.

    In the meantime, organizations need to work on work on bridging the long-standing divide between application development and cybersecurity teams. Historically, cybersecurity teams would aggregate vulnerabilities they discovered in spreadsheets that developers would then be asked to remediate. The issue is not only the lack of time to address those vulnerabilities but also the lack of context provided. Many of those vulnerabilities often turn out to not be applicable to the way an application is deployed. Over time, application developers start to ignore many of those requests in favor of focusing their efforts on writing additional code. Of course, the more code that is written the greater the number of vulnerabilities that need to theoretically be remediated until a vicious cycle is created.

    Of course, it’s only a matter of time before one vulnerability winds up being a critical exploit and becomes the exception to that rule.

  • Continuous Delivery Advances Come at Cost of Testing

    Continuous Delivery Advances Come at Cost of Testing

    A survey of 820 application development professionals conducted by Applitools, a provider of an application testing platform, found well over a third of respondents (38%) working for organizations that now deploy daily changes to production environments.

    The challenge is that application testing is not able to keep pace with that rate of continuous deployment (CD). The survey found organizations are seeing test suites covering less than 50% of applications.

    Applitools COO Moshe Milman said a major reason test coverage is so low is that more than 40% of respondents said their continuous integration (CI) test suites can take more than an hour to run, which often resulted in tests either being postponed or possibly not run at all, he noted.

    Most organizations are also still relying on manual testing processes that can’t keep pace with the accelerated rate of application deployment and subsequent updates, added Milman. More than half of organizations (55%) automated less than half of their testing, according to the survey. More than two-thirds of respondents (67%) are embracing test automation to improve their test coverage, the survey found.

    In general, the percentage of organizations that are now employing CD processes to accelerate the pace at which applications are deployed is steadily increasing, said Milman. Manual testing processes, however, slow down the rate at which organizations deploy code. Many organizations routinely make trade-offs between application quality and a need to deploy code faster. Inevitably, there will be issues that can be traced back to decisions to not adequately test code prior to deployment, noted Milman.

    Overall, the survey found 90% of respondents building and deploying web applications, followed by 52% that were building and deploying mobile applications. Only 30% are building desktop applications. Testing of the applications, however, tends to vary widely. Nearly two-thirds of respondents (65%) said they tested applications on an end-to-end basis, with 55% testing integration followed by unit testing (53%) and application programming interface (API) testing (51%).

    However, only 26% tested application performance, followed by 13% that tested security and 12% that tested load, the survey found.

    Part of the issue, of course, is that it’s not always clear who is responsible for application testing. In theory, developers are accepting more responsibility for application testing as they take more responsibility for managing applications on an end-to-end basis. In practice, developers are often rushing to make application development deadlines. It’s not uncommon for developers to skip or limit testing in the name of productivity. Many of them have also embraced agile development methodologies that, at least theoretically, allow them to address any issues that might arise via the next application update.

    The issue that arises is that end users have become less tolerant of experimentation. If an application doesn’t initially work as expected, it’s exceedingly difficult to regain user confidence. Many will simply evaluate another similar application. The irony, of course, is that in the race to deliver code faster, application experience winds up being sacrificed because of the lack of time to properly test an application before deploying it.