devopsy.kinsta.cloud

Tag: secure code

  • Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb today added an ability to instantly surface patches for vulnerabilities at the time when code is being committed during a DevSecOps workflow.

    Previously, the tool provided by Mobb to create validated patches based on the scan results of third-party SAST tools would only surface issues to individual developers.

    Mobb CEO Eitan Worcel said organizations can now address these issues within the context of DevSecOps workflow.

    The Mobb platform combines proprietary security research and traditional semantic analysis with generative artificial intelligence (AI) to automatically create patches for vulnerabilities. The overall goal is to make it simpler for DevSecOps teams to consistently ensure applications with known vulnerabilities are remediated before they are deployed, said Worcel.

    The Mobb approach eliminates the need for IT teams to sort through static application security testing (SAST) scans themselves. Each vulnerability typically requires at least 30 minutes to fix, so the Mobb platform improves application security while simultaneously making developers more productive.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool automatically creates the necessary patch, so there is less of a need to debate which vulnerabilities are worthy of the time required to create a patch.

    For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing software supply chains as part of a larger effort to improve application security.

    There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that address common vulnerabilities.

    The process by which patches are prioritized, developed and then applied has, of course, long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities. The challenge is finding a way to remediate vulnerabilities that developers will embrace rather than resist. The Mobb approach still provides them with control over what patches are applied but the toil involved with creating a patch in the first place has been substantially reduced.

    It’s not clear how long it might be before automated approaches to building patches might improve the overall state of application security but, as always, every journey needs to begin with a first step in the right general direction.

  • The Cyber Resilience Act Threatens the Future of Open Source

    The Cyber Resilience Act Threatens the Future of Open Source

    The European Union (EU) is currently considering approval of the Cyber Resilience Act (CRA), a proposed regulation that is a major threat to the future of the global open source industry. While the intention of the act is to enhance cybersecurity (which is extremely welcome), its current form lacks clear liability exemptions for many open source developers and maintainers, which could be a death knell for open source in the EU and which could spark additional, global implications.

    The CRA regulation for the EU was proposed on September 15, 2022, by the European Commission. The intent is to improve cybersecurity and cyberresilience in the EU through common cybersecurity standards for products with digital elements. In theory, this is welcome. But there are some notable areas that many open source developers and industry organizations are concerned about.

    Modern applications are comprised of 90% open source code; penalizing open source developers would lead to a fragmented community and hinder important projects across various sectors, including critical infrastructure, health care and even military systems.

    The seemingly purposeful omission of exemptions for open source would put undue onus on open source foundations and maintainers and poses a serious risk to not just EU innovation and security but global collaboration. Something we, and many others in the industry, have tried to raise awareness about over the past six months. Unfortunately, the EU has largely ignored the industry’s voice. Holding open source developers whose components end up in commercial products liable for security issues will stifle innovation and harm the EU economy without providing a substantive improvement in security.

    This legislation is slated for a vote on July 19 in the parliament’s Industry, Research and Energy (ITRE) committee, where it will then be sent on to the full parliament. And, if nothing is done, it could be adopted without even a vote in a plenary session by the Parliament itself. I feel strongly that if the open source industry doesn’t take a stand now, it will become law and the open source community as we know it will be no more.   

    There are two main problems with the proposed CRA: It discourages commercial support of open source and imperils vulnerability disclosure.

    CRA Discourages Commercial Support of Open Source

    The revised CRA offers new cybersecurity requirements for hardware and software products, much like the U.S.’s National Cybersecurity Strategy does. It calls for software vendors and producers to understand what components are in their software and to be able to recall software that is affected by a vulnerability. But, unlike the recently released details for the U.S. strategy, it seems to be trying to call out certain open source projects from foundations and large companies. By doing so, it potentially impacts every open source project, which creates a web of issues.

    It goes without saying that open source projects rely heavily on volunteers, individual contributors and small teams who often work without significant resources or financial support. The support that foundations and contributors do get often comes from commercial entities who have adequate resources to provide developer time to give back to the community.

    The current CRA text only excludes OSS software that has no commercial activity around it. Unfortunately, it defines commercial activity in part, this way:

    “where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.”

    This can be read to mean that if the main contributors are not unemployed, then the project is commercially tainted. It does not clarify what was probably intended—that the employer fully controls the project here.

    Additionally, it says:

    “Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature.”

    The first part is acceptable, but recurring donations from commercial entities are the upside of contributing back to open source. This may force the projects to reject large contributions to avoid becoming “tainted,” and will likely cause commercial entities to enact further bans on OSS contributions and pull their support entirely.

    Further, if the CRA is passed without proper exemptions, these developers and maintainers may face legal risks and liabilities for vulnerabilities found in code used in commercial products. The OSS developers have no visibility into how and in what instances their components are used; only the final manufacturer of the product has this visibility.

    The potential legal risk, without an upside, would discourage OSS developers from contributing to and maintaining open source projects. This situation not only undermines the spirit of open source but could bring about an open source crisis and isolate the EU from the rest of the world. Non-EU open source producers will avoid the EU market, meaning no access to Linux, Apache, Kubernetes and many other projects. Repositories like Maven Central, npm and PyPi may be prompted to ban EU consumption to avoid being considered a distributor. EU projects concerned about liability could pull their source code off the internet, and EU businesses may be forced to halt contributions to open source projects.

    CRA Imperils Vulnerability Disclosure

    The regulation also would require that vulnerabilities be disclosed to the European Union Agency for Cybersecurity (ENISA) within hours of discovery, whether or not a fix is available. This would make it difficult to conduct coordinated disclosure—where researchers give vendors time to develop security patches before vulnerabilities are disclosed publicly. This would increase the chances that bad actors will develop exploits for the vulnerabilities before they are fixed, putting every company that uses that software at risk. This would be an unfortunate outcome for a law whose purpose is to improve security of software.

    What Can we Do?

    As I mentioned earlier, time is of the essence since this measure is moving quickly and faces a vote this week. We need the community to take immediate action. GitHub and other industry bodies need to publicly oppose the proposed measure. EU developers, maintainers and others need to ask their European Parliament Members (MEPs) to investigate further and bring the voices of the open source community to the discussion.

    Legislators need to understand the importance of collaboration and the role of the global developer community in driving open source innovation. Open source projects underpin much of the software we use every day. It’s the lifeblood of the internet. Legislation that deters contributors would interfere with the open source community’s ability to maintain existing projects and deliver new software, impacting the tech industry, hurting the EU economy and compromising overall software security.

  • I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines

    I Guess This is Growing Up: Devs and CISA’s Secure-by-Design Guidelines

    With the downward pressure of a global recession, inflation and general post-pandemic turbulence underpinning disruption to multiple facets of life, it seems only fair that we in the IT, software and security industry would eventually feel the winds of change, too. We have rolled with the punches of escalating cybercrime and data breaches; the collective, fragmented sheriffs of a digital Wild West, and it’s high time we updated our strategy for safeguarding software against bad actors who seek to do widespread harm.

    The recently released National Cybersecurity Strategy signals the need for a seismic cultural shift for most companies and their developers and DevOps teams. The most glaring recommendation comes in the form of security accountability that falls primarily on software vendors. This is a positive step, though it is sure to cause teething problems, especially as many organizations struggle to accurately assess their security maturity across the board, particularly among the development cohort.

    Since CISA Director Jen Easterly’s trailblazing speech on secure design principles, we have eagerly awaited formal guidelines on how, exactly, organizations can approach this significant restructuring of software development as we know it. Thanks to a collaborative effort between the cybersecurity authorities of seven countries, we have a rather comprehensive overview of how to drive down vulnerabilities in software.

    This should be cause for celebration, but understandably, there is hesitation about how this will impact innovation, feature delivery and, ultimately, the bottom line as the pressure of security stewardship mounts for vendors. We’ve grown accustomed to dealing with cumbersome tooling that is ill-fitted with developer workflows, overwhelming them with a list of fixes in an information avalanche. Add SCA and SAST scanning, and you’ve got thousands of identified issues in a codebase that are just not practical to solve. 

    Despite this, in terms of our collective attitude towards code-level security, is it time we grew up and faced the music?

    Security Commitment and Transparency Boost Our Potential

    Back in March, the White House announced that one of its top priorities in the National Cybersecurity Strategy was to shake things up and start holding entities liable for sloppy software security measures:

    “Companies that make software must have the freedom to innovate, but they must also be held liable when they fail to live up to the duty of care they owe consumers, businesses or critical infrastructure providers,” the White House noted in the strategy.

    In the era of “speed at all costs” software development, my opinion may be unpopular, but I truly stand behind the idea that coding with security front-of-mind from the beginning is the only way we safely create our digital future. We were already facing insurmountable challenges with data breaches, nation-state attacks and infrastructure disruption, and that was before code-capable AI tools hit the mainstream. Until every person touching code cares more about the security implications of their actions, we will continue to see cybersecurity issues surge at a rapid rate.

    I know this is easier said than done. I have a lot of empathy for those standing at the bottom of this steep mountain trying to change the conversation around security accountability and enable developers in their organizations to share responsibility. To adequately fulfill key secure-by-design principles in software development, it is going to require precision training that establishes a basic skillset before deep-diving into more advanced security architecture methods. Developer-led threat modeling is a golden opportunity for the AppSec and development teams to work together toward a common goal and explore access control and insecure design pitfalls that plague less mature organizations.

    Still, the core issue has always revolved around a lack of ownership for security (until something goes wrong—then it’s the AppSec team left holding the bag) coupled with a low appetite for best practices to be established and executed across every part of the SDLC. The truth is, it was never acceptable for developers to start coding with so little security expertise, nor for us to focus on speed and functionality at the expense of safety and quality. Yet, here we are, and this is our crucible moment to accept shorter-term pain for longer-term ongoing success.

    We should want to create the most secure, robust software possible, and the “radical transparency” called for by Jen Easterly is a boon to vendors and clients alike. It is definitely a mark of value to showcase the company’s security prowess; brand trust and reputation are everything in this hyper-competitive landscape.

    Developers Need Guidance and Support to Thrive in a Secure-by-Default Environment

    The CISA guidelines pay particular attention to open-source and third-party components, both of which are widely used in most software development projects. It is imperative that developers are sufficiently security-aware to navigate potential inherent bugs with any preexisting code they use. However, in addition, they must be able to apply working knowledge of security fundamentals in the languages and frameworks they actively write in every day. Annual compliance videos played at 2x speed won’t cut it; they need training and a tech stack that is hyper-relevant, easy to access without context-switching from their workspace and that ultimately drives them to apply secure coding best practices as second nature.

    They cannot do this alone, and they can’t be expected to upskill in their own time. The cultural shift required to make the development team a fundamental cog in a thriving security program takes courage, time and commitment. But the reward is cohesion between AppSec and developers that would have been virtually impossible a decade ago and software that stands above those who are, in one way or another, happy to let security slide despite the risks.

    I guess this is what growing up looks like for all of us in the software industry, and it’s crucial if we want to stop the same old vulnerabilities that have plagued us for so long that they are old enough to drink.

  • ReversingLabs Adds Ability to Detect Secrets in Application Binaries

    ReversingLabs Adds Ability to Detect Secrets in Application Binaries

    ReversingLabs today announced it added an ability to detect secrets exposed in application binaries to its Software Supply Chain Security (SSCS) platform.

    Tomislav Peričin, chief software architect for ReversingLabs, said this addition will make it easier for DevSecOps teams to identify secrets that are inadvertently left in applications as plain text or that can be discovered because of weak cryptography, scripts that have been included in directories that have secrets configuration files, packaging automation mistakes, compromised developer accounts or the activities of malicious insiders.

    The SSCS platform can identify more than 250 secret types out of the box, including private keys, version control, certs, tokens and more. Once they are identified, the platform also surfaces their precise location, which services are affected and if those secrets are exposed or leaked elsewhere. The platform also identifies third-party, open source, testing keys and other commonly shared secrets in addition to which secrets have already been exposed. Armed with those insights, it then becomes possible to better prioritize remediation efforts on actionable issues to reduce overall manual triage fatigue, noted Peričin.

    ReversingLabs also provides guidance for sensitive information policies, including documentation of public exposures and breakdowns of secrets used for web service access credentials, web service access tokens, web service API keys and webhook service access keys.

    Most software composition analysis (SCA) tools used to secure software supply chains are limited to identifying issues in source code. As applications become more modular, however, the odds authentication credentials such as login credentials, application programming interface (API) tokens and encryption keys might be left exposed because of a developer mistake substantially increase. The overall goal is to make it possible for DevSecOps teams to discover these issues in binary code before an application is deployed, noted Peričin. That “just in time” approach to secrets management includes canary token management and custom detection policies to better ensure application security.

    In general, secrets within applications are becoming more challenging to secure as cybercriminals increasingly scan repositories and continuous integration/continuous delivery (CI/CD) platforms to find them. The ultimate goal is to inject malware into a software component that will be used in multiple downstream applications. Once activated, that malware will then create a backdoor through which cybercriminals can exfiltrate data or launch a full-blown ransomware attack. It was the latter type of attack that led to the U.S. government creating a formal National Cybersecurity Strategy to, in part, lock down the software supply chains employed by federal agencies to build applications.

    A recent survey published by ReversingLabs, however, found that while 87% of respondents agreed that software tampering has become a more frequently used cybersecurity attack, only 37% said they have any means to detect it. Only 7% said they could detect software tampering at each phase of the software development life cycle.

    It’s not clear to what degree best DevSecOps practices are currently being implemented within application development teams, but as more attacks are launched against software supply chains, it’s now only a matter of time before most DevOps teams are routinely required to scan code for exposed secrets and known vulnerabilities long before code is allowed anywhere near a production environment.

  • GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian published an analysis of more than one billion commits to GitHub repositories that found 10 million occurrences of secrets, with one out of 10 developers exposing a secret.

    Mackenzie Jackson, a developer advocate for GitGuardian, said more than 80% of all the secrets caught by live monitoring GitHub were exposed through personal repositories, with a large share of them being corporate secrets. In fact, three million of the secrets discovered were unique instances, with 5.5 commits out of every 1,000 made exposing a secret.

    On a year-over-year basis, the report also found that the number of hard-coded secrets discovered in these repositories increased 67%. More than half the secrets discovered (56%) contained a generic password.

    There appeared to be no correlation between developer experience and the number of secrets exposed. Junior and senior developers are equally predisposed to making the same mistakes, said Jackson. The most common mistake is secrets left exposed because developers used them to simplify access to components and resources when building their applications and then forgot to remove them when the application was deployed in a production environment.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. The issue with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have issues with how secrets are managed could be staggering.

    In theory, at least, the adoption of DevSecOps best practices should be mitigating this issue, but as the volume of code stored in repositories continues to increase, it would appear more fundamental mistakes are being made. Cybercriminals, meanwhile, have a greater appreciation today for weaknesses in software supply chains, so many of them are scanning repositories for secrets that will enable them to breach an application.

    Of course, there’s a lot more attention being paid to secure software supply chains, especially in the wake of the Biden administration creating a National Cybersecurity Strategy that requires Federal agencies to, among other things, lock down software development life cycles on an end-to-end basis. Most enterprise IT organizations, if they have not done so already, are expected to follow suit.

    As a result, DevOps teams should expect to see more cybersecurity professionals focusing more on secrets management. Developers, naturally, will not want to be called out for mismanaging secrets, so over time, the overall state of application security should steadily improve. The issue, of course, is the volume of attacks against software supply chains is expected to increase. Many previous mistakes are likely to come back and haunt developers and the organizations that rely on their code and wreak havoc downstream.

  • Report Identifies Top 10 Open Source Software Risks

    Report Identifies Top 10 Open Source Software Risks

    Endor Labs, a provider of a platform for managing open source software, published a report that classifies the top 10 open source software risks of 2023. The company published the list as part of an effort to better educate application development teams about issues that can lead to software supply chain compromises. That list includes:

    Known Vulnerabilities: A version of a software component may contain vulnerable code that is accidentally introduced by its developers. When vulnerability details are publicly disclosed, there may not be a patch readily available.

    Unmaintained Software: A software component may not be actively developed or maintained anymore, resulting in patches for functional and non-functional bugs not being provided in a timely manner—if they’re provided at all.

    Name Confusion Attacks: Attackers may create components whose name resembles the names of legitimate open source or system components. This is also known as typosquatting. Bad actors might also attempt to mimic trustworthy authors (brandjacking) or play with common naming patterns in different languages or ecosystems (combosquatting).

    Compromise of Legitimate Package: Attackers may compromise resources that are part of an existing, legitimate project or associated distribution infrastructure to inject malicious code into software components.

    Outdated Software: A project may use an old, outdated version of a software component even though a newer, more secure version exists.

    Untracked Dependencies: Developers may not be aware of a dependency on a component because it is part of another upstream module they employed.

    License Risks: A software component or project may not have a license at all, may have one that is incompatible with the component’s or project’s intended use or whose requirements are not or cannot be met.

    Immature Software: An open source project may not apply development best practices such as having a standard versioning scheme or lacking a regression test suite, review guidelines or documentation.

    Unapproved Changes: A software component may change without giving developers the chance to notice, review or approve such changes because the download link points to an unversioned resource, a versioned resource has been modified or tampered with or due to an insecure data transfer.

    Unknown Origin: Details about the source code, build process or the distribution process of a software component may be unknown or non-verifiable.

    Endor Labs CEO Varun Badhwar said organizations need more visibility in the potential operational risks that come with increased reliance on open source software. That doesn’t mean organizations should use less open source software, but there are issues that many development teams may not always appreciate. A recent analysis of nearly 2,000 software packages published by Endor Labs, for example, found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer employed an open source component.

    Regardless of the root cause, responsibility for application security continues to be pushed left toward application developers. The challenge is it’s not possible to achieve that goal without first knowing what issues developers and the DevSecOps teams that support them need to be focused on. Perfect application security is, of course, unattainable, but any reduction in the number of vulnerabilities littering the software landscape will go a long way toward reducing the current level of stress developers and DevOps teams experience.

  • Benefits and Challenges of DevSecOps for Business

    Benefits and Challenges of DevSecOps for Business

    Almost every day, there is a new tactic or technique discovered that hackers can use to disrupt a company’s systems, obtain critical data and information or steal money. Often attackers look to exploit vulnerabilities in code to carry out their attacks. Ironically, it’s usually a small piece of code that helps a business perform very simple tasks that can become the root of this serious issue (e.g., logging, report service and glue for application). In fact, it only takes one exploitation, vulnerability or human error to cause a data breach that, on average, costs $4.35 million. Some experts projected that by 2025, these breaches could cost a total of $10.5 trillion. Therefore, CEOs and other corporate executives should reflect on these incidents to ask themselves what would happen if someone entered their systems to exploit code and what it could mean for their company.

    The Problems That a Business Faces

    In traditional development practices, security serves a ‘gating’ function. Security checks are performed prior to releasing an application to production and, if issues are found, security stops rollouts. This can have disastrous ramifications.

    The unknown can be frightening, but that’s where DevSecOps can help. DevSecOps incorporates security into every step of the software development life cycle (SDLC) from requirements to architecture and design, coding, testing, release and deployment. By automating and integrating security practices into the software development life cycle, development teams can react to vulnerabilities sooner, automate security checks and proceed into production with a more reliable and secure product.

    The benefit is felt when a tactical vulnerability is discovered and the DevSecOps practice is already in place to ensure that it can be remediated with limited impact on the business.

    The Business Benefits of DevSecOps and Best Practices

    Streamlining the SDLC and including security checks (often automated) in the process early in the development cycle can identify a problem before it can negatively affect the bottom line of the development effort and the business. Having a vulnerability remediated early in the development cycle is an order of magnitude less expensive than one discovered just prior to production.

    DevSecOps works best in an organization where Agile practices have been adopted to swiftly enable continuous integration, deployment and scalability. The road to streamlining and automating these practices can be long, but when effectively applied, DevSecOps best practices reduce costs for the company and accelerates time to market.

    For DevSecOps to be effective, security must have a seat at the table when requirements are gathered and architectures are planned. This integration of work practices ensures that risks are identified early and can be mitigated well before an application is launched in production.

    Using that same connection with operations, security procedures should be established to feed new vulnerability discoveries into the pipeline for remediation. However, implementing DevSecOps isn’t a magic fix and it won’t happen immediately. But why can it be so hard to implement?

    Overcoming the Challenges of DevSecOps

    There are many difficulties when it comes to implementing DevSecOps. Here are two of them:

    1. Cultural Shift:
    Leading with a DevSecOps approach requires a huge culture shift within the organization that challenges the way many departments operate today. Many employees might find it difficult to drastically change what they’ve been doing for years. Another roadblock is the belief that better protection slows down processes and restricts innovation. Quick code production is a goal for developers who want to meet the demands of businesses, while on the other hand, security teams are focused on making sure the code is secure.

    Thorough training for both security and development experts will help overcome some cultural obstacles but integrating the goals and objectives of both teams will push the adoption of DevSecOps practices. Organizations will begin to see security align to faster time and flexibility of solutions while developers will begin to adopt a security-first mindset.

    2. Complex Tool Integrations:
    Most DevOps toolchains are produced by different vendors. Teams select source code management, continuous integration/delivery (CI/CD), build tools, binary libraries, code review and problem monitoring solutions based on their unique needs. Adding security tools into that pipeline can create a challenge for ensuring the best results for both teams.

    Security analysis in the development pipeline is done with tools that perform software composition analysis (SCA), static application security testing (SAST), and some form of dynamic testing. Integration into the pipeline of these tools is significant and creates difficulties for developers. The developer must know the intent of the scan and what to do with the problems they uncover. It is important that developers have an accurate understanding of where the problem arose and what the issues mean. However, combining and comparing the results and data of many vendors’ resources might be challenging.

    The best course of action would be to consolidate your solutions. This will not only make things simpler for the developer and the organization, but it may also reveal threats that the organization wasn’t previously aware of.

    Overcoming these obstacles is not an easy task, but it is possible. Once a DevSecOps approach is accepted and fully implemented across your company, you can expect code to be developed with fewer bugs and security risks. The cost of deploying code will also eventually decrease, and at a pace that helps the organization maximize its return on investment. Overall, systems created within this process will be significantly more flexible and capable of adjusting to modern-day threats and change in the midst of a digital transformation.

  • Rezilion Updates Open Source MI-X Tool to Better Secure App Development

    Rezilion Updates Open Source MI-X Tool to Better Secure App Development

    Rezilion has updated its open source MI-X vulnerability discovery tool to include mitigation and remediation recommendations.

    In addition, the tool can now produce machine-readable output in either a JSON or CSV format.

    Finally, the company added Windows support for Heartbleed and SpookySSL vulnerabilities in Windows environments.

    MI-X makes it possible to use a command line interface (CLI) tool to identify and establish the exploitability of more than 20 well-known common vulnerabilities and exposures (CVEs).

    Yotam Perkal, director of vulnerability research for Rezilion, said Rezilion created the tool as part of its efforts to create a platform that enables organizations to better secure their software supply chains. The primary purpose of the platform is to prevent vulnerabilities from being introduced into applications in the first place by providing developers with the context required to understand the potential severity of a vulnerability, he added.

    There’s no doubt that developers need tools that enable them to easily identify vulnerabilities while writing code. However, shifting responsibility for vulnerabilities entirely left toward developers is not a panacea for application security. DevOps teams need to embrace DevSecOps best practices to ensure that the build created by multiple developers is secure and that the runtime environment where applications run is also free of malware.

    The challenge is that achieving that goal needs to go beyond adding additional tools to a DevOps workflow. The biggest challenge is narrowing the historic cultural divide between developers and cybersecurity teams tasked with discovering vulnerabilities. Most cybersecurity professionals don’t understand how applications are developed, so every instance of vulnerability found in an application looks the same to them—regardless of whether the actual code is externally accessible.

    DevOps teams, meanwhile, are trying to strike a delicate balance between patching innumerable vulnerabilities and building and deploying additional applications. More than anything, those teams need to be able to prioritize their patching efforts based on the actual versus theoretical severity of a vulnerability, noted Perkal.

    It may never be possible to address all the application security debt application environments have accrued over the years. However, as apps are built and application security issues are addressed more proactively, the state of cybersecurity should improve. The issue, of course, is that cybercriminals are now targeting software supply chains; inserting malware into a DevOps workflow creates a potential opportunity to compromise any number of downstream applications. Organizations are now racing against time to secure their software supply chains.

    The good news is that no developer intentionally sets out to build an insecure application. It’s just that far too many of them have been conditioned to think of security as an obstacle they need to overcome rather than address. However, the more tools they are provided to remediate as many vulnerabilities as possible, the better off everyone concerned will be.

  • How SASE Can Ease DevSecOps Adoption

    How SASE Can Ease DevSecOps Adoption

    DevSecOps is a software development methodology that merges development (Dev), security (Sec) and operations (Ops) into one team that integrates security throughout the entire software development life cycle (SDLC). The goal is to deliver high-quality applications quickly and securely.

    The traditional software development life cycle introduces security in the late phases of the SDLC. However, this approach cannot protect against sophisticated cybersecurity attacks. Today’s cybersecurity landscape requires shorter, frequent iterations to quickly patch and fix security issues. DevSecOps integrates security into the continuous integration and continuous delivery (CI/CD) pipeline to ensure teams can address pressing security issues at DevOps speed. 

    Many organizations are enthusiastically adopting DevSecOps but, in the process, discover they don’t have the necessary infrastructure. DevSecOps requires smooth global collaboration between teams and requires that security controls are built into the IT environment. This is where SASE comes in.  

    What is Secure Access Service Edge (SASE)?

    Secure access service edge (SASE) is a network security model that provides network connectivity with security based on identity, real-time security context and corporate security policies. It is aligned with the zero-trust security paradigm, ensuring that connections are denied by default unless a verified identity has permission to access a specific application, service or edge location. 

    SASE unifies networking and security functions into one fully integrated service delivered in the cloud. SASE includes several technologies: software-defined wide area networking (SD-WAN), secure web gateway (SWG), cloud access security broker (CASB), next-generation firewall (NGFW) and zero-trust network access (ZTNA).

    A key benefit of SASE is enhanced network security. SASE services enhance network security with a granular approach to network protection, detecting and blocking network attacks such as distributed denial of service (DDoS) attacks, man-in-the-middle (MitM) attacks, phishing, email spoofing and malware with deep security scans. 

    Additional benefits of SASE include: 

    • Lower cost compared to traditional networks because SASE includes fewer on-premises hardware components and features previously purchased from multiple vendors. 
    • Easier maintenance because it provides one pane of glass that allows IT teams to manage all applications and users wherever they are. 

    Components of SASE

    Cloud-access Security Broker (CASB)

    CASB acts as a bridge between users/devices and cloud applications. It allows organizations to apply security policies, two-factor authentication and single sign-on to all cloud applications, preventing unauthorized devices and individuals from accessing sensitive assets and denying access by default.

    Zero-Trust Network Access (ZTNA)

    ZTNA ensures that users or devices have explicit permission to access applications or resources. It is a critical component of a zero-trust security architecture, ensuring that internal, private applications are hidden from users who should not have access to them. It also enables secure remote access through layered authentication. ZTNA provides flexible security to meet modern security requirements.

    Software-Defined Wide-Area Networking (SD-WAN)

    SD-WAN is a connectivity architecture that separates network hardware from the physical control layer. It improves network performance by enhancing and simplifying WAN performance and management. SD-WAN supports modern, cloud-based applications and services while reducing connectivity costs. Combining SD-WAN with advanced security features provides a foundation for enterprises to transition to SASE.

    Secure Web Gateways (SWG)

    SWG protects online devices from malware infection, enforces corporate security policies and filters unwanted websites in user-initiated internet traffic. SWG provides URL filtering, application control, DLP, antivirus, sandboxing and SSL inspection. All these capabilities protect users from harmful websites and enforce security policies while ensuring full web access and promoting productivity.

    Firewall-as-a-Service (FWaaS)

    FWaaS is a firewall solution delivered as a cloud-based service. It provides hyperscale next-generation firewall (NGFW) features, including web filtering, advanced threat protection (ATP), intrusion prevention systems (IPS) and domain name system (DNS) security. By integrating FWaaS into the SASE platform, organizations can provide a wide range of cybersecurity capabilities at the edge.

    Centralized and Unified Management

    The modern SASE platform enables IT administrators to manage SD-WAN, SWG, CASB, FWaaS and ZTNA with centralized, unified management across networks and environments. This allows IT team members to focus on more pressing areas and improves the user experience for the organization’s mixed workforce.

    How SASE Will Impact DevSecOps and Security in Organizations

    SASE can help secure internal interactions and applications. As a result, the burden on DevSecOps teams is reduced. DevOps teams can use zero-trust network access (ZTNA) to further secure the applications running on SD-WAN. These technologies keep all interactions between endpoints and applications secure.

    The SASE model can also help protect mission-critical applications and sensitive data that cannot run on the public internet. To protect these assets, SASE obfuscates traffic, restricts access with a zero-trust architecture, and secures all network entry points with NGFW. It continuously evaluates application traffic for security threats.

    Facilitating Collaboration 

    DevOps teams are focused on time-to-market and are constantly working to accelerate the CI/CD pipeline. They need to collaborate remotely over a reliable and secure connection. DevOps teams are also working to reduce their reliance on network and security teams. The SASE model helps address these problems.

    SASE helps reduce collaboration issues by unifying WAN and network security. SASE solutions provide optimized performance and strong security, so DevOps teams don’t depend on infrastructure staff to provision resources. It gives teams full control over operations without compromising performance or security.

    Providing Built-In Security

    SASE offers the basic network security features required to secure a DevOps project. This allows teams to integrate different security mechanisms into their networking stack, with all security services sharing an integration context. This plugs the gaps in traditional security architecture often exploited by attackers and protects applications from threats.

    Improving Incident Response

    SASE can immediately block various attack vectors with security controls embedded in the network fabric, supporting the incident response team’s efforts. SASE increases visibility into behavioral anomalies and security incidents in a hybrid environment.

    Integrating SASE solutions into a security information and event management (SIEM) system allows incident responders to gain greater visibility into traffic anomalies and the automated security actions taken by the SASE tools. SASE features like NGFW, SWG, IPS and anti-malware might already contain or eliminate many incidents.

    Providing More Reliable Infrastructure 

    DevOps teams need fast, reliable application performance. SASE offers integrated load balancing and failover capabilities that can significantly improve the network’s overall performance. 

    The SASE architecture can connect all the edge devices, remote users, data centers and cloud resources to a secure, self-healing, fully optimized global network. If a circuit fails or the path becomes congested, the fabric can automatically switch to an alternate path.

    Conclusion

    In this article, I introduced DevSecOps and showed how SASE, a modern platform that provides fast network connectivity and security at the edge, can support its adoption. DevOps teams can use SASE security components to secure applications across on-premises data centers and clouds. SASE can encrypt and inspect traffic to protect it from threats, ensuring that workloads, users, and development systems are secure by default. 

    With SASE, DevSecOps teams have the infrastructure they need to secure the environment and can focus on integrating security tests and remediations into the development life cycle.

  • Shift Left Testing in Microservices Environments

    Shift Left Testing in Microservices Environments

    By now, it’s common knowledge that the later a bug is detected in the software development life cycle (SDLC), the longer it takes and the more expensive it is to fix that bug.

    In 2017, the Ponemon Institute found that it cost around $80 on average to fix a defect detected early in the SDLC and around $7,600 to fix the same defect if it was detected in the production stage.

    Relative Cost of Fixing a Defect Based on Development Stage

    Design

    Implementation

    Testing

    Maintenance

    Cost of Fixing Defects

    1x

    6.5x

    15x

    100x

    While these numbers can be debated, it’s clear that early detection of defects can save organizations significant time and money while enabling those organizations to deliver higher quality software more rapidly. For these reasons, many organizations are implementing shift left testing practices, including in microservices environments.

    Shift left is a set of practices intended to find and prevent defects early in the software delivery process instead of during the testing and maintenance stages. The idea behind shift left testing is to improve software quality by making actionable test signals and feedback available as early in the SDLC as possible.

    Here, we’ll highlight how shift left testing, in combination with test automation, can better enable both innovation and fast delivery of high-quality software. We’ll also address some of the challenges involved in implementing shift left testing in microservices environments, as well as introduce a valuable strategy for successful microservices implementation.

    Shift Left Testing Benefits

    The waterfall model of development involved the explicit passing of responsibilities between highly specialized design, development, QA, and release teams. It also involved lengthy feedback loops.

    Scrum and agile methodologies made the entire SDLC more flexible and nimble by introducing sprints and allowing more frequent iterative development and delivery. Further, DevOps and DevSecOps focus on removing the silos between development, operations, and security through tooling and automation. As a result, the time to market and quality have improved dramatically. Adding shift left testing into the mix better positions teams to handle the broad range of responsibilities from the design stage through the maintenance stage as effectively as possible.

    Shift left testing focuses on prevention rather than detection. Shift left benefits include the following:

    • Increase efficiency by eliminating bugs earlier in the SDLC.
    • Reduce human errors and associated costs.
    • Increase delivery speed and reduce the time between releases.
    • Improve the quality of software.
    • Gain a competitive advantage.

    It may be helpful to think of shift left testing like this: Test early and in parallel with development, instead of the traditional waterfall model of development followed by QA testing. 

    Shift Left Testing Challenges in a Microservices Environment

    By structuring an application as a collection of loosely coupled, independently deployable services, a microservices architecture enables frequent delivery of large, complex applications.

    While shift left testing practices bring many benefits, shift left testing also comes with three challenges that organizations must address when implementing it across a decentralized, microservices-based stack:

    1. Building and managing each microservice separately reduces development time. However, implementing shift left testing at the microservices level means shift left practices must be applied to each individual microservice.
    2. Microservices developers can choose the programming language and service dependencies best suited to their development needs. However, as a result, shift left testing practices need to be implemented and managed across different programming languages and dependencies.
    3. To ensure that microservices function as expected, teams usually run integration tests, end-to-end tests, and performance tests that assess functionality in the context of the larger stack. Shift left testing is especially challenging in the microservices context because of the complexity of testing against the stack.

    Microservices, each with their own SDLC pipeline

    Pipeline Scaling Considerations

    Several classes of automated shift left tests can be integrated into the DevOps pipeline, including unit tests, integration tests, performance tests, and security tests. Different microservices will have different testing needs.

    The key is to apply shift left testing practices to each microservice while maintaining the flexibility and decentralization of those microservices. The ideal workflow system and DevOps pipeline implementation must simplify pipeline creation while enabling development teams to manage the pipeline and requiring minimal input from DevOps and platform teams. In other words, shift left practices must be tailored to the specific needs of the microservice in question to make the testing process scalable and easy for development teams to manage on a continuous basis.

    As just one example, GitHub Actions and similar CI/CD pipeline tools enable development teams to use GitOps-based practices to configure, manage, and administer the entire pipeline for their microservice while leaving infrastructure testing and testing that relies on or affects other parts of the system to DevOps teams.

    Test Environment Considerations

    Test environments are environments where unit tests, integration tests, performance tests and security tests can be run on an isolated collection of microservices and configurations. The nature and quality of these test environments directly correlate with the effectiveness of shift left testing.

    A cloned production or staging environment can be used for testing when the number of microservices is low and overall complexity is relatively low. However, once an organization reaches a threshold number of microservices or a threshold level of complexity, runaway infrastructure costs and operational burdens make such environments untenable.

    In response, some organizations rely upon smoke testing (minimal viable stability testing) and mock-based integration testing early in the SDLC. While such tests can prove useful in the near term, deferring essential testing to a later stage in the SDLC often introduces test signal and validity problems in the staging environment and can lead to delivery delays and serious issues with software quality.

    So how can shift left testing be used successfully in a microservices environment? The solution involves the use of scalable, ephemeral test environments.

    Ephemeral Shift Left Testing Environments

    The availability of high-quality test environments is a common bottleneck for organizations looking to scale shift left testing practices. Using a few high-fidelity staging environments for signal testing can slow the release process. More to the point, it tends to slow down the entire SDLC and increase stack instability over time.

    Ephemeral test environments offer a fundamentally different approach. These sandbox environments use isolated environments that enable users to test independently without impacting other users. In particular, they enable isolation while sharing resources (e.g., external cloud dependencies and hosted databases) using application-level multitenancy instead of the resource duplication approach in traditional environments.

    The idea is that microservice test environments can be used to test changes against a much larger stack of services. Because multiple tests can be conducted at the same time, test coverage and resource efficiency vastly increase.

    High-quality sandbox environments can spin up in seconds and scale to tens of thousands of microservices. In fact, each pull request, branch, or commit can have its own test environment without significantly increasing infrastructure and operational costs. Any change, no matter how small, can be tested in isolation to ensure performance and stability against the entire stack.

    Shift Left Testing Solutions for Microservices

    A microservices-based organization looking to scale shift left testing across the organization must first address several challenges. Considerations include the need to apply testing practices to separate microservices, the need to accommodate different programming languages and service dependencies and the need to test against the stack.

    The right tooling and automation are needed before shift left testing practices are scaled across the organization. In addition, a cultural shift may be required in order to help developers understand the ways in which shift left testing can expedite and improve the core functionality that they are developing.

    To apply valuable shift left testing practices in a microservices environment, organizations should consider using ephemeral sandbox environments. Using the right set of tools in a sandbox environment can enable development teams to test microservices throughout the SDLC. In doing so, organizations can ensure those services follow security best practices and perform exactly as intended, both independently and against the stack–all while reducing costs, speeding time to market and improving software quality and user satisfaction.