devopsy.kinsta.cloud

Tag: devsecops

  • How DevSecOps Addresses Supply Chain Security

    How DevSecOps Addresses Supply Chain Security

    “The absence of security in the initial stages of system engineering is the single most significant cybersecurity gap and risk in modern system development.” This quote from tech entrepreneur Linda Rawson is a good reminder for the current cybersecurity threat situation. With software supply chain attacks increasing in aggressiveness and sophistication, organizations need to understand that cybersecurity should no longer be an additional process, let alone an afterthought.

    Integrating security in the software development process provides a few other benefits, including better efficiency and customer satisfaction. However, its most notable benefit is addressing cybersecurity threats more effectively compared to the conventional ways of enabling software security.

    The Rise of DevSecOps

    DevSecOps is a fast-rising star in today’s search for effective cybersecurity solutions. The DevSecOps market is expected to be worth $23.63 billion in 2030, growing at a CAGR of 23.84% in the forecast period 2023-2030. Its value in 2022 was estimated at around $4.27 billion.

    This double-digit growth is actually a bit conservative. Other forecasts showed higher CAGRs in the 30% range. This growth hints at the strong demand for DevSecOps solutions. Many organizations have started to acknowledge the benefits of implementing security validation methods early in the software development life cycle (SDLC) instead of doing them in bulk as a separate phase at the end of the development process.

    Many organizations are now convinced that they can benefit from shifting left or bringing security into the SDLC earlier. Tools and solutions like static code analysis (SCA), automated dynamic analysis, interactive application security testing (IAST) and source composition analysis address security weaknesses before an application is released to the market. This allows organizations to release apps faster and, because of the elimination of most bugs and vulnerabilities, provide considerably better user experiences.

    Vulnerabilities will never be completely eliminated, but they can be significantly reduced and more properly resolved while software is being developed if security validation is integrated in the development process. Some software defects and weaknesses tend to be more difficult to address through a separate security testing process, since it would entail a broader code tracing or review as opposed to quickly spotting the affected code when security validation is done alongside the development process.

    Addressing Software Supply Chain Attacks

    So, how does DevSecOps help prevent supply chain attacks? The key is in the visibility and control DevSecOps affords.

    DevSecOps requires vigilance of security issues throughout the software development process. Security is not relegated to a different team that doesn’t understand the specifics of a development project. As such, the team has broad visibility over security concerns. Because the DevSecOps team also has mastery of the code being developed, it is easy to trace the origin of vulnerabilities and implement the necessary corrections.

    DevSecOps is aided by automated tools that scan code for security issues and detect threats even before they manifest themselves as problems. These tools are used across all phases of the development process, from the time code bears basic features and functions to deployment and post-production.

    Static testing: Even before an application’s code is ready to run, it can be subjected to static testing to find vulnerabilities. Tools such as static application security testing (SAST) can analyze code and detect possible security problems.

    How does this address software supply chain attacks? Static testing can be overlaid on automated CI/CD pipelines to stop code that has security weaknesses from getting committed to the codebase.

    Dynamic testing: An automated dynamic analysis can be used for code that is already executable. This is done through dynamic application security testing (DAST) tools, which are capable of detecting vulnerabilities usually invisible to SAST but which are detectable once the code is running.

    How does this address software supply chain attacks? Organizations can implement automated black-box testing for apps in the CI/CD pipeline(s) to detect security flaws for apps that are already executable. This addresses the vulnerabilities that have not been detected by static testing while reducing the costs associated with the corresponding remediation.

    Interactive app testing: This is a combination of static and dynamic testing. It employs IAST tools which run static testing on available code and come up with bespoke dynamic tests for a specific app to identify issues more thoroughly.

    How does this address software supply chain attacks? Pure static and dynamic testing usually apply to earlier stages of the development process, whereas interactive testing addresses vulnerabilities that emerge in the later parts. By bringing IAST to the CI/CD pipeline, organizations achieve better security issue detection outcomes, which means the prevention of malicious code deployment.

    Supply chain analysis: This entails the use of tools that specifically examine the security of third-party libraries and dependencies. To be clear, this is not the only method for addressing software supply chain vulnerabilities. In this case, supply chain merely refers to the external libraries, dependencies and other components that do not originate from the development team.

    How does this address software supply chain attacks? Integrating software chain analysis tools in the CI/CD pipeline significantly reduces the adverse effects of vulnerabilities in dependencies and other components on a project’s codebase as well as on the development process itself.

    Security-as-Code

    One of the best practices developed in line with the integration of security in the software development process is the idea of implementing security-as-code. This means that security policies and measures such as testing and validation are turned into code whenever possible. In other words, the code itself already bears security mechanisms. Security testing runs automatically whenever code is committed. This ensures robust, consistent, highly scalable security that does not rely on external rules and mechanisms to prevent the introduction of anomalous code or malicious inputs.

    Security-as-code also means that the DevSecOps team can see how modifications to code and the underlying infrastructure are created. The team can map out the impact of code changes and identify the areas where security tests and regulations can be implemented to optimize processes and avoid unnecessary delays.

    Security-as-code is essentially the automation of security practices. It is not applicable in all instances, though, so it is still important to be knowledgeable about security testing methods that can be used in different stages of the development process.

    Securing the Software Supply Chain

    The SUNBURST incident and other similar high-profile attacks should serve as a warning for all organizations to ascertain the security of their software supply chain. DevSecOps is one of the best solutions right now. It does not guarantee the complete elimination of all threats, but it ensures that if threat actors succeed in getting around security controls, a breach won’t go unnoticed.

     

  • DevOps Onramp: Security on the Rise

    DevOps Onramp: Security on the Rise

    I don’t normally advertise stuff in my blog, because that’s not what it is here for. It is here to offer you the thoughts and ponderings of someone like you, and advice you didn’t ask for. But today we’ll make an exception since I also blathered for Techstrong Group recently, and soon you’ll be able to hear it.

    If you are not familiar with it, DevOps Onramp is this week, and you can go and register to hear my session and the sessions of other great voices that are involved in DevOps. My session is about DevOps and Security, but there are a wide variety of sessions for you to choose from.

    I am trying to make the time to be involved in the conversation when my session airs, and it looks like my schedule will allow it, so if you are interested in DevOps security, I’ll likely be around to discuss it with you.

    I can’t speak for all of the sessions, but mine starts with the basics for newcomers and then covers more advanced topics as it goes on. The truth is that I was supposed to do two sessions–intro and advanced, but I started talking too fast, and the next thing you know, I crammed it all into one session, saving you time for some of the other great content that is available at the show.

    So (virtually) drop by, watch my session, see what else you’re interested in, and feel free to drop any of us presenters a line telling us what you think, good and bad. I’m sure the show organizers would be happy to receive feedback too, but I’m all about presenters.

    And keep rocking it. We’ll be back next week with our regular content (and no ads).

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    SiriusXM
    Associate Director for Software Delivery
    Deerfield Beach, Florida
    $157,000 or $250,000

    SimplyHired

    Nagarro
    Remote
    Senior Staff Engineer – DevOps
    $155,000 to $196,000

    Dice.com

    Engage Partners
    Davie, Florida
    DevOps Architect
    $130,000 to $160,000

    Indeed.com

    ServiceNow
    Orlando, Florida
    Staff DevSecOps Engineer
    $114,000 to $144,000

    Monster.com

    Swift Group
    Fort Belvoir, Virginia
    DevOps Engineer
    $80,000 to $180,000

  • Codenotary Previews Secure SBOM Creation Service

    Codenotary Previews Secure SBOM Creation Service

    Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

    Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

    Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

    Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

    In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

    Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

    More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

    It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

    On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • GitLab Survey Reveals DevSecOps Gains

    GitLab Survey Reveals DevSecOps Gains

    A global survey of 5,010 IT leaders, CISOs and developers published by GitLab this week found well over half (56%) of respondents are working for organizations that are using DevOps or DevSecOps practices. However, 72% of respondents said they are using a DevSecOps platform (36%) or are considering adopting one in the next year (36%).

    Overall, less than a third of survey respondents (30%) said they were “completely” responsible for application security, with 53% reporting they are part of a larger application security team. Well over a third (38%) of the 1,453 security professionals surveyed said they are part of a cross-functional team focused on security.

    License compliance checks and security capabilities for cloud-native or serverless tied for the top of the list of current priorities (19%), but shifting security left (29%) was the top focus for the coming year. Nearly three-quarters (74%) of security professionals said their organizations either shifted left or plan to in the next three years. Nearly as many (71%) said a quarter or more of all security vulnerabilities were discovered by developers.

    Top frustrations identified specifically by security professionals included testing happening too late in the development cycle (43%) and difficulty prioritizing vulnerability remediation (41%).

    Those frustrations might increase in the coming year, with 85% of security professionals reporting they either have the same or lower budget in 2023.

    On the plus side, nearly two-thirds of the 1,954 developers surveyed said they are either using artificial intelligence (AI) and machine learning (ML) algorithms in testing today or will be in the next three years. A full 62% said they used AI/ML to check code, while 53% use bots for testing and 36% use AI/ML for code review.

    Nevertheless, more than two-thirds of security professionals (67%) said they are concerned about the impact of AI/ML capabilities on their job, with 28% of them admitting they are “very” or “extremely” concerned. Of those respondents who expressed concern, 25% said they are worried about the potential for AI/ML to introduce errors that will make their job more difficult.

    David DeSanto, chief product officer at GitLab, said GitLab is also working to address those concerns by embedding a range of AI/ML capabilities into its platform to optimize DevSecOps workflows and, most recently, enhanced its GitLab Remote Development module to make it easier to centralize the maintenance and security of development environments.

    GitLab this week also announced it is partnering with Oracle to make it easier to use the GitLab continuous integration/continuous delivery (CI/CD) platform to run AI and ML workloads on the Oracle cloud platforms. AI/ML is going to play a critical role in enabling organizations to build and deploy secure code without slowing down the pace of application development, said DeSanto. In fact, many organizations will soon be consolidating toolchains to enable them to achieve that goal, he added.

    The GitLab survey found 57% of security respondents said they use six or more tools, but many of those tools are legacy software composition analysis (SCA) tools that will be replaced as more responsibility for application security shifts left toward developers, noted DeSanto. Two-thirds of survey respondents (66%) reported they want to consolidate their toolchains this year.

    Collectively, the GitLab survey makes it clear that DevOps and DevSecOps practices and platforms continue to evolve rapidly. The challenge, as always, is keeping up with the pace of that change.

  • How Application Developer Turnover is Shaping Security

    How Application Developer Turnover is Shaping Security

    Observing the developer job market for the past two years reveals a surprising truth that has a profound impact on technology organizations. In the “new normal” of hybrid work, life moves fast and there’s no sign of slowing down. Since 2021, we’ve witnessed all-time record demand for software engineering developers. The emergence of privately held large and medium technology startups, fueled by a fear of missing out (FOMO) driven venture capital market, created vast growth opportunities for software engineer developers in particular. From developing and deploying new applications to scaling your business through multi-cloud environments, cloud and cloud-native companies are everywhere. Not only are cloud and cloud-native companies receiving enormous funding rounds, but worldwide spending on public cloud services is forecasted to grow 20.7% to a total of $591.8 billion in 2023.

    This dramatic cloud growth is primarily driven by the warp speed developers are operating. Thanks to developers, every company is now a digital company and every industry is reaping the benefits of a cloud presence. A retail organization can now build and deploy an application for the holiday shopping season within hours, and workforces can access applications from their kitchen, local coffee shop, or halfway across the world.

    However, as with any new, widely adopted technology, cybercriminals look to target and exploit organizations in their early cloud days as they begin to grasp and understand the technology.

    It was reported earlier this year that the recent exposure of roughly a terabyte of Pentagon emails was likely due to a cloud configuration error. Cloud attacks are on the rise, and there is a major disconnect about who is responsible for keeping the organization safe. Developers who are told to build with speed don’t want their applications slowed down or user experience to be altered by security protocols. Still, accelerating application velocity has security teams caught between remaining responsive to application teams and securing an increasingly complex cloud environment. A major problem is bubbling up, and if security and developers teams cannot come together, the result can leave organizations vulnerable.

    Developers and Turnover

    In a recent survey, 75% of respondents reported a higher-than-usual turnover rate in DevOps. Similar to the well-documented cybersecurity talent shortage, multiple workplace stressors appear to be taking a toll on developers. The same survey reported that 38% of enterprises deploy code to production or release to end users every day, with 17% deploying multiple times a day. To put this into perspective, just two decades ago, developers were shipping limited updates one to two times a year.

    Given the pressure to deliver new code every day, combined with security teams’ pressure to ensure that code is secure, it’s no surprise that we’re witnessing higher-than-normal developer attrition. Instead of pointing fingers at developers for unsecure code, security teams need to create tools and training that do not impede their number one priority: Shipping new code. We’re in a developer-friendly job market and organizations cannot afford to lose top talent because they are overburdening them with security tasks. Developers will find greener pastures.

    Shifting Left

    By now, everyone in the industry has heard of shifting security left—the practice of moving security to the earliest possible point in the development process to ensure code is secure and limit timely and costly remediation. In practice, this means bringing security to where the developers operate so vulnerabilities and misconfigurations are caught early when they are easy to fix.

    This approach has brought about a deeper level of engagement between application developers and security teams, especially in the design phase. However, while developers might now be embracing tools and processes that help them code secure applications, there’s still a limit to how much shift left responsibility they can and want to handle.

    Path Forward

    Shifting security left is certainly a recommended starting point, but simply equipping developers with DevSecOps tools isn’t a winning approach. Developers must be trained and have the desire to effectively use the tools. Like the old saying, give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime. The same holds when shifting security left.

    To ensure developers and security teams understand their security responsibilities within the organization, consider implementing the following:

    1. Define a clear shift left strategy with developers and security teams
    2. Provision the necessary security tools that effectively protect the organization but don’t create roadblocks for developers. Additionally, more tools don’t necessarily mean more security, so be strategic.
    3. Train developers to be more mindful of cybersecurity issues. Most developers haven’t had formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed

    DevSecOps is as much about changing culture and approaches as it is about acquiring new tools. Developers will, unfortunately, come and go, but it should never be because security teams are overburdening them.

  • A DevOps Guide to the Language of DevSecOps

    Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:

    • Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
    • Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
    • Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
    • High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
    • Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.

    What is DevSecOps?

    DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

    It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

    DevOps Guide to Security Acronyms

    All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

    1. SBOM—Software Bill of Materials

    A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

    2. DAST – Dynamic Application Security Testing

    DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

    3. SCA – Software Composition Analysis

    SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

    4. SAST – Static Application Security Testing

    SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

    5. IAST—Interactive Application Security Testing

    IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

    6. RASP—Runtime Application Self-Protection

    RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

    7. OWASP—Open Web Application Security Project

    OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

    8. XDR—Extended Detection and Response

    XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection. 

    9. XSS—Cross-Site Scripting

    XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data. 

    10. SQLi—SQL Injection

    SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

    11. CSRF—Cross-Site Request Forgery

    CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

    12. SAML—Security Assertion Markup Language

    SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO). 

    Conclusion

    In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline. 

    The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

    Image Source 

  • Android Apps Must Let Users Delete Data ¦ RISC-V in the Data Center

    Android Apps Must Let Users Delete Data ¦ RISC-V in the Data Center

    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: Google forces apps to make deleting users’ data easier, and the RISC-V drumbeat grows louder. (more…)

  • Synopsys Preps Extensions to Polaris SaaS Platform

    Synopsys Preps Extensions to Polaris SaaS Platform

    Synopsys plans to extend the capabilities of its Polaris Software Integrity Platform for securing application development environments by adding dynamic application security testing (DAST) tools along with the ability to scan code used to provision infrastructure.

    As a software-as-a-service (SaaS) platform, the Polaris Software Integrity Platform was created by combining the static application security testing (SAST) tool Synopsys gained with the acquisition of Coverity in 2014 and the software composition analysis (SCA) tool it added to its portfolio by acquiring Black Duck Software in 2017.

    In 2015, Synopsys acquired the Seeker tool for analyzing the code created using interactive application security testing (IAST) tools from Quotium. The company last year acquired WhiteHat Security from NTT to add a DAST tool.

    Patrick Carey, senior director for marketing strategy for Synopsys, said that the company would add the capabilities of those latter two platforms to create a comprehensive set of best-in-class security tools that are easily accessible via a SaaS platform.

    At a time when more organizations than ever are moving to secure software supply chains, Carey said it’s critical to provide developers with more visibility into vulnerabilities across the entire software development life cycle (SDLC). Some organizations are opting to achieve that goal by embedding tools within the SDLC themselves, but many organizations would likely prefer to invoke a SaaS platform that they don’t have to maintain, noted Carey.

    He noted that a SaaS platform makes it simpler to point a collection of integrated tools at a code repository to surface those vulnerabilities.

    As DevSecOps workflows continue to evolve and mature, more responsibility for application security is shifted left toward developers. The challenge is that many developers have limited cybersecurity expertise, so it’s critical that they have access to high-quality security tools.

    In addition, a SaaS platform helps reduce the total cost of achieving that goal by providing multiple capabilities within a single integrated platform, said Carey.

    Naturally, most of the focus today is on reducing the number of vulnerabilities that find their way into production environments as applications are being built. However, there are already large numbers of unaddressed vulnerabilities in applications that have already been deployed. Organizations will need to find ways to address that technical debt in addition to providing developers with tools that help prevent those code vulnerabilities in the first place.

    As such, there is no one central place through which application security can be managed, noted Carey. Instead, application security needs to be addressed across every phase of the SDLC, he added.

    It’s not clear how quickly organizations are adopting DevSecOps best practices, but as calls for increased liability for software development increase—as outlined, for example, in the U.S. National Cybersecurity Strategy— organizations should expect DevSecOps workflows to become a requirement. Otherwise, organizations will be severely penalized for vulnerabilities that find their way into code. In effect, there is now a race to embrace DevSecOps before any proposed liability legislation becomes the law of the land.