devopsy.kinsta.cloud

Tag: devsecops

  • How to Secure Fintech Applications and Protect Customer Data

    How to Secure Fintech Applications and Protect Customer Data

    All industries are feeling the pain of preventing rising risks to their applications, private information and customers’ data, and it is not surprising that this is especially true in the financial services sector. In fact, fintech companies on average spent more than $18 million in 2019 battling cybercrime, while other markets’ companies spend an average of $13 million addressing cybersecurity concerns each year.

    While these numbers can be depressing, a recent virtual roundtable we hosted with some of the best AppSec brains in fintech uncovered three steps organizations can take to secure their fintech applications and protect their customer data. The panel included Erick Lee, director of Security at Intuit; Jeremiah Kung, first vice president and global head of digital cybersecurity at East West Bank; and Karthik Rangarajan, security lead at Robinhood.

    The panel discussed AppSec trends, best practices for what is working in their organizations and recommendations for security leader peers who are tasked with addressing application security at their organizations. The group agreed that there’s a lot of creative thinking and exciting work happening around AppSec, and that includes across all of DevOps and engineering, not just those charged with application security. These notions can’t help but leave one feeling optimistic.

    While the spirited discussion covered a variety of topics and trends, here are the three high-level recommendations organizations should follow to best secure their fintech applications.

            1. Make sure AppSec teams are hiring software engineers. The panelists agreed that security and engineering functions should not operate as separate entities. One participant described why he hires software engineers instead of security engineers. He explained that software engineers know how to create fixes and operate at scale, which is critical for his organization, which manages 1.5 million requests per second. Since many organizations do not have the resources to hire a security engineer, particularly smaller and growing groups, it is especially important to build security into the engineering team.Organizations tend to discover scalable methods of solving problems and accelerating the development process when engineers are engaged with security. Take for example a security concern that delayed an application release. The panelists agreed that unless the issue is a show stopper, security should not delay a release, unless of course there is a compliance concern or potential violation. They recommended for developers do their thing, and let security work hard and try to keep up.

              The panelists explained this is because companies need to keep pace and release products and triage at scale. This is especially true in the fintech space, where winning business is about application features and capabilities. As an example, one panelist illustrated how his company’s focus is trying to ensure developers have paved roads so they can get “speed to benefit to customers.”

              To make this happen, his company deployed tools for automation, such as solutions that scan GitHub code for potential issues. They are also leveraging automation to monitor for security problems all through production. The punch line for them is to make security complementary and seamlessly woven into the workflow, it cannot be a secondary process slowing development.

           

          1. Compliance should be approached as an engineering problem. A significant challenge for financial services companies and fintech continues to be adhering to governance and compliance requirements. One of the reasons is a lack of automation and solutions that scale, which come at significant costs. In fact, one-third of global financial services companies spend more than 5% of their budget just on addressing compliance.Many financial services organizations rely on spreadsheets, PDFs, paper files and email chains to address and prove compliance. Fintech companies continue to address compliance questions using paper documentation and manual work. These methods are clearly not scalable and not sustainable for growing organizations to meet their expanding compliance demands.

            Fortunately, as the panelists uncovered, compliance and governance can be viewed through an engineering lens, as they have seen happen at some of the best fintech companies. One panelist illustrated that at his company he met with compliance experts to learn precisely about their problems, so his team could engineer solutions. After discovering the issues and metrics needed to prove compliance effectiveness, his team introduced automation and new tools to address the issues. His company knows the compliance methods are working if the metrics are being met, he said.

            Another panelist added that meeting regulatory compliance within a global organization like his introduces additional challenges of meeting compliance requirements in multiple jurisdictions. But the need to understand where data is and how it is being kept safe is common across the board. If you can address those questions, he said, then proving that the data is safe becomes the main task.

            For development and application security to remain sustainable, compliance cannot remain manual and human based. The panelists agreed that it’s unlikely to be able to fully automate all of the reporting and processes needed, but with a goal of 80% automation and 20% manual methods, organizations will be in a much better position.

          2. Security must be proactive. This is a common theme in our industry these days, and it certainly was popular thought the entire roundtable discussion. The panelists highlighted that fintech engineering teams are thinking about compliance and security in a variety of proactive ways. One panelist recalled that he asks his teams to “lean into security and do right by the customer before the company is asked to do so.”

      The areas addressed throughout the discussion ranged to a variety of topics, including how these days security is kept top of mind for engineering leaders during the hiring process. Participants agreed that hiring an AppSec developer is like finding a unicorn. The trick they said is to be more proactive and nurture your own unicorns internally. This can be accomplished by focusing on hiring top security developers and growing them into security roles. The result has significant benefits on all sides. The company will build its AppSec resources and expertise, and employees can value the opportunity to grow and expand their experiences into new areas they may not have known before.

      The panelists highlighted that exploring ways to ensure and accelerate approval for security features is a good way to ensure proactive security. One approach is to connect compliance issues that need addressing with security advancements. For example, if the goal to help prevent customer data loss is to add two-factor authentication, one should link a compliance issue that can also be solved by the requested security solution. Decision-makers may look to save budget and pass on simply adding security features, but it will be more difficult to say no to a compliance request. This kind of creative strategic thinking has a way of being a win-win for the company as well as its customers.

      The success of AppSec among financial services organizations depends on more than just effective security protocols that secure companies and protect customers. It needs creative, innovative and strategic ideas to enable organizations to have efficient, economical and scalable security. If that sounds like something your organization is seeking, then according to our roundtable panelists our industry has a very bright future.

  • DevOps’ Role in Fixing Software Vulnerabilities

    DevOps’ Role in Fixing Software Vulnerabilities

    From the beginning, application development has required that software developers deal with bugs, vulnerabilities and other issues. But problems encountered under the DevOps model tend to be more manageable since the updates and fixes required are usually smaller. The reason for this is that the process of maintaining and improving DevOps-related software never stops. In other words, problems that do need to be corrected are typically tackled faster under the DevOps model.

    In looking at the DevOps cultural shift that has fast-tracked the software development process while making security part of that process, it’s critical to consider how the DevOps process impacts software development, the issues around hackers taking advantage of vulnerabilities in code and why companies need to protect their infrastructure that incorporates speed and security.

    How DevOps Practices Impact Software Development

    DevOps practices impact every level of the software development process. In the past, software developers would churn out new app versions, sometimes every few years and sometimes every couple of months.

    This afforded developers sufficient time to go over their code with a proverbial fine-tooth comb. It also allowed them to devote more time to quality assurance efforts, which helped to minimize vulnerabilities that hackers could use to their own advantage.

    But the rise of DevOps has drastically revolutionized the way software is developed and delivered to customers. Instead of releasing new versions of apps perhaps yearly, software developers operating under the DevOps model can release updates and fixes quickly and on an ongoing basis.

    Facilitating the software development process over the course of the DevOps life cycle are tools such as Jenkins or Docker that allow the automation of many procedures and applicable processes.

    Quite simply, DevOps practices positively impact software development. The benefits can be broken down into three categories, namely technical, cultural and business, and as can be seen below:

    1. Technical Benefits: Ongoing software development, less complexity to take on and faster resolution of problems or issues.
    2. Cultural Benefits: Teams more fulfilled and productive, greater worker engagement and more professional development options.
    3. Business Benefits: Speedier delivery of features, more durable operating environments and better collaboration.

    It goes without saying that DevOps has a major and even revolutionary impact on the process that software development teams use to create applications as well as to fix vulnerabilities. It proves that doing things faster doesn’t have to mean proceeding in a haphazard manner.

    Issues Around Hackers Exploiting Code Loopholes

    Implementing the right processes and procedures can cut down on exploitable vulnerabilities. But software developers understand that hackers wake up each morning scheming up new ways to exploit code and infrastructure, which is why the struggle never stops. One of the issues customers are justifiably concerned about is privacy.

    The answer is to take DevOps to the next level. In other words, software developers need to adopt the DevSecOps model, which refers to implementing open source security procedures in the beginning stages of the software development life cycle. Open source security measures are essential for DevOps security teams because of the fact that they are lower cost, more innovative and allow teams to make the most of their continuous delivery processes. This includes, but is not limited to, code analysis, vulnerabilities assessments and compliance monitoring.

    When software teams purposefully and intentionally implement security practices within an Agile framework, they will be able to safeguard the integrity of their codebase. This can be accomplished with continuous evaluation, testing and updating.

    Why Businesses Need to Maintain Fast and Secure Infrastructures

    More companies are investing in protecting their infrastructure than they ever have before, as infrastructure protection spending this year could reach $17.5 billion worldwide, up from $12.6 billion in 2017. So while there is crystal clear evidence that more companies recognize the need to protect their infrastructure from nefarious actors, they are also, in fact, doing something about it.

    The consequences of failing to maintain a fast and secure infrastructure can be disastrous. Consider the following statistics that show some of the problems that can materialize: On average, it takes 206 days just to identify a data breach, and over 30% of companies encountered cyberattacks on operational technology infrastructure last year alone.

    So what can software development teams do to help organizations maintain secure infrastructures at a time where hackers are tirelessly persistent? While customers expect software to be delivered post-haste, they also expect it to be secure.

    Software developers need to commit to DevOps and DevSecOps to ensure that the software they develop and deliver to customers is free of exploitable vulnerabilities that could jeopardize their infrastructure, scare off their clients and even potentially wreck their operations altogether.

    Customers also have a role to play to keep their infrastructure safe. They should, for instance, have policies in place to govern how their workers use the software, roll out updates and fixes as soon as they are available, and use the right tools to protect their infrastructures.

    Conclusion

    By leveraging the DevOps model to make security part of the corporate culture and by training team members so that everyone adopts coding habits that are rooted in security, and by automating security in the development process, software development teams can deliver safe products quickly.

    At a time when customers expect deliverables fast, software development teams need DevOps so they can go from the development stage to the delivery stage without needless delay. The DevSecOps model is one in which security is purposefully implemented at each stage of the software development process, not simply a value-added component.

  • GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech today launched a CodeSentry software composition analysis (SCA) for binaries that inventories third-party code used in custom applications and identifies known vulnerabilities.

    Vince Arneja, chief product officer for GrammaTech, said the bulk of custom applications today are made up of binaries based on components developed by a third-party that comes in the form of open source, commercial-off-the-shelf (COTS) or existing custom software.

    CodeSentry detects these components and vulnerabilities associated with third-party code, including network components, graphical user interface (GUI) components or authentication layers. It uses deep binary analysis to create a detailed software bill of materials (SBOM) and a comprehensive list of known vulnerabilities.

    Arneja said that as responsibility for security continues to shift left toward developers, there is a need for tools such as CodeSentry that make it easier to identify vulnerability issues in binaries because many developers may not have access to the underlying source code used to construct the binary. CodeSentry identifies components present in native binaries using a range of matching algorithms to gather version number ranges, create an SBOM and provide links to CVE and CVSS scores, said Arneja.

    CodeSentry extends algorithms that GrammaTech developed to detect components in applications, including strings used in natural language processing. It maps components to multi-dimensional vectors and compares them to vectors derived from the components. The upload interface for the tool accepts native binaries, zip files and other archives. Once those files are loaded, CodeSentry analyzes the code that will run rather than the build environment to reduce the number of false positives that would be generated in build environments or components that are not actually being employed.

    GrammaTech next year intends to make CodeSentry available via a software-as-a-service (SaaS) platform, noted Arneja. GrammaTech ultimately envisions CodeSentry being employed as part of DevSecOps workflows driven by a continuous integration/continuous delivery (CI/CD) platform using a set of open application programming interfaces provided by the company, said Arneja.

    While there’s a lot of focus these days on melding DevOps and cybersecurity workflows as part of an effort to embrace best DevSecOps practices, the easiest vulnerability issue to resolve is the one that never existed in the first place. As developers gain access to cybersecurity tools, the number of vulnerabilities making it into applications should significantly be reduced in the months ahead. The challenge IT leaders face is making sure developers have access to those tools, which in turn will ultimately boost the confidence level cybersecurity teams have in application developers, who are often viewed as the primary cause of the problems cybersecurity teams are trying to resolve.

    Regardless of how IT organizations achieve that goal, the return on that investment is likely to be substantial. The amount of time and effort IT teams spend tracking down vulnerabilities that are much more expensive to fix after an application is deployed in a production environment is incalculable.

  • How to Successfully Integrate Security and DevOps

    How to Successfully Integrate Security and DevOps

    As digitalization transforms industries and business models, organizations increasingly are adopting modern software engineering practices such as DevOps and agile to become competitive in the modern marketplace. DevOps enables organizations to release new products and features faster, but this pace and frequency of application releases can conflict with established practices of handling security and compliance. This leads to the enterprise paradox to go faster and innovate but stay secure by avoiding compromises on controls.

    However, integrating security into DevOps efforts (DevSecOps) across the whole product life cycle rather than being handled independently or left until the end of the development process after a product is released can help organizations significantly reduce their risk posture, making them more agile and their products more secure and reliable. When properly implemented, DevSecOps offers immense benefits such as easy remediation of vulnerabilities and a tool to mitigate against cost overruns due to delays. It also enables developers to tackle security issues more quickly and effectively. Getting security right from the start is important due to the growing dependence of companies on digital technologies that can make them more susceptible to cyberattacks, in which an attacker can utilize a system flaw possibly created due to unfamiliarity toward security as a business priority.

    DevSecOps integrates various security challenges into the coherent approach of software delivery. Some best practices followed in DevSecOps throughout the software development life cycle are:

    • Planning and Designing: From the inception, teams are aware of their security responsibilities and trained to handle them. Since the start teams quickly model threats and risks. Product backlog items (PBI) are prioritized in a way to make the product secure and compliant. Architectural design is developed in collaboration with security experts.
    • Coding: Developers practice secure and resilient coding practices. Full advantage is taken of reusable coding patterns and microservices to meet common security requirements for encryption and authentication.
    • Reviewing: Both automated and manual checks are used to review codes as part of regular agile sprints. After that, peer reviews are conducted by senior developers to make sure that software meets appropriate standards.
    • Testing: Automated security tests are run alongside automated functional and performance tests to confirm that testing is consistent. Automated penetration tests look for security cracks in systems as part of every sprint and release cycle.
    • Deployment: Automated processes are used to deploy code securely and reliably into production-hosting environments that can be rapidly invoked through APIs.
    • Operations: In production, automated processes such as real-time monitoring, intrusion detection and compliance validation are used to detect vulnerabilities. Product reliability and security are constantly checked to detect vulnerabilities and prioritize resolutions.

    The success of adopting DevSecOps principles relies on avoiding common pitfalls. The mere implementation of DevOps tools across the organization cannot support the effectiveness of DevOps. To get it right, companies need to:

    • Create a more integrated operating model making privacy and security principles as integral parts of the company culture.
    • Build secure and reliable services.
    • Wherever possible, automate development and release processes.
    • Continually evolve product architectures.

    Leaders play an active part in steering the transformation by endorsing security and privacy at the board level. At the same time, CISO and compliance leaders need to make certain that greater agility does not come at the cost of higher risk.

    Often organizations focus on software security as a business priority only after they are affected by a data breach. But when an organization is impacted by cybercrime, along with the costs of data damage, IP theft and business disruptions, it incurs legal and PR fees, drops in share price and the potential loss of customers and competitive advantage.

    Companies that implement DevSecOps best practices benefit from numerous advantages. Substantial costs can be curtailed by detecting and fixing security issues in the early phases of development, which indirectly leads to an increased speed of delivery and recovery.

    A secure and reliable product has the potential to increase sales. Following best practices leads to the creation of immutable infrastructure and utilization of cloud-based infrastructure that helps improve overall security by reducing insecure defaults, increasing code coverage and automation.

    Automated application testing, automated security review of code and empowering developers to use secure design patterns ensure the “secure by design” principle. In DevSecOps the responsibility for security is shared and encourages a culture of openness and transparency from earlier stages of development and enables constant iterative improvements.

    A central belief of DevSecOps is that security is an integral and essential aspect of DevOps. By adopting DevSecOps best practices in their product development cycles and avoiding common pitfalls, companies can stay current, acquire agility and strengthen their security to withstand exposure to cyberattacks.

  • DevSecOps: Changing AppSec for the Midmarket

    DevSecOps: Changing AppSec for the Midmarket

    The midmarket space has always been prime for innovation and opportunity. In the DevSecOps space, that is no different.

    If you look at this report or others about DevSecOps markets, two things stand out:

    1. The market is expected to explode to $14 billion by 2026 from today’s nominal $2 billion.
    2. The biggest driver of the increase is the rise of security adoption by midmarket enterprises.

    Software is eating the world, as everything is becoming digitized. In response, midmarket companies are rapidly cranking up web and mobile apps to better compete and serve their customers. Along with the increase comes a dependency on apps for critical business functions and a need to secure them from attacks, which explains the surge in security demand.

    Current AppSec Offerings Are Not Geared for the Midmarket  

    AppSec Expertise Required

    Most incumbent AppSec products were built at least a decade ago when only large enterprises cared about AppSec. Naturally, they were molded for the characteristics of those enterprises. They are unnecessarily deep and monstrously complex and require a team of AppSec experts to begin operations. Midmarket companies don’t have the skills, resources or willingness to hire a team of AppSec experts, especially given their short supply.

    Extraordinarily Expensive

    Incumbent AppSec products are dreadfully expensive for midmarket companies. Annual prices reach millions of dollars and it’s difficult to determine ROI, making decisions murky for budget-conscious midmarket companies. They want to produce and deliver secure apps and certainly want to mitigate risk, but they also have a lower ceiling they can afford to pay.

    A New AppSec Approach for the Midmarket

    Being Cloud-native Requires SaaS AppSec

    Midmarket companies are quicker to adopt a cloud-native approach. Unlike large enterprises, they don’t have the baggage of legacy tech and can move to the cloud more easily. Being cloud-native saves a lot of money and comes naturally to the midmarket—when it comes to AppSec, they are likely to require that products be cloud-native and SaaS. Most security incumbents started on-premises, and although some now have a parallel SaaS offering, they are clunky and not designed inherently for cloud-native architectures.

    Rise of DevOps and CI/CD Automation

    As cloud adoption increases, automation of deployment to the cloud becomes a key factor, resulting in the meteoric rise of DevOps. DevOps uses many tools to automate cloud integration and cloud deployment, with CI/CD tools consistently at the center. AppSec must be part of this automation process, preferably in the CI/CD. The manual waterfall approach cannot work with the new speed and volume of application development. If scanning is not automated in the CI/CD, scans simply don’t get run. Therefore, because the automation workflow starts with DevOps, AppSec needs to be DevOps-first.

    Traditional AppSec scanners were not built for DevOps. Sure, some have caught up and added DevOps to their marketing material. Several have even added some integrations, but their core product remains much the same and it’s not DevOps-friendly.

    One significant offshoot of DevOps-first AppSec for the midmarket is that the tool cannot require AppSec expertise, simply because most DevOps don’t have significant AppSec expertise. Requiring that knowledge to get the security automation workflow started is a non-starter.

    Open to Open Source Scanners … With Management

    Midmarket companies are typically willing to use open source primarily because it is free. Unlike large enterprises with their tendency to complicate anything, midmarket companies have fairly standard requirements that can usually be met with open source. It is no different when it comes to application security scanners, and midmarket enterprises are fans of these tools. Often the scanning prowess of these open source scanners is better than their commercial counterparts, as they are tailored and specialized to specific languages and architectures. They also cover all scan types (SAST, DAST, SCA, etc.) and a combination of them can provide an efficient and affordable level of security.

    This midmarket love affair with open source scanners comes to a screeching halt when it becomes apparent that it is grossly unmanageable. There are so many available open source scanners that it takes time to decide which are relevant for your organization, application and development status. They are also notoriously difficult to set up, upgrade and maintain. Each of them does things differently. The output or reporting formats are not normalized across scanners. Without an aggregation layer to consistently cross-reference, normalize and present a consistent view of the security risk, consuming the output is nearly impossible. This often results in midmarket companies choosing to select only one type of scan.

    Imagine a tool that adds a common SaaS orchestration layer that crosses all these scanners and scan types, using their superior scanning prowess, but removing the management headache. Midmarket companies would improve their security posture with an investment they can afford. This sort of “Open Source + SaaS” model is not new. Applying the model to application security changes the game for midmarket companies.

    One Tool for all Scanning

    The multiple types of application security scans make application security complex. SAST scanners scan the source code for vulnerabilities, DAST scanners scan running applications from the outside in, SCA/OSS scanners scan third-party libraries included in your application, container scanners scan containers, API scanners scan exposed APIs, Secrets scanners scan for open passwords in the source code, and so on. Mentioning all these distinct scanners can make heads spin for those inexperienced with AppSec. This complexity is worsened for midmarket companies. For most, it is nearly impossible to keep up with the new pace of application development with unaffordable, piecemeal scanners from multiple vendors or the multiple open-source scanners needed to address each area of vulnerability.

    Security is only as good as the weakest link. Even if you do an exemplary job with one type of scanning but leave out other types you leave gaping holes in your security and risk. What midmarket companies need is one tool that tackles application security comprehensively by automating and orchestrating the use of all types of scans while abstracting the user from the underlying complexities.

  • Using PAM to Support the ‘Sec’ in DevSecOps

    Using PAM to Support the ‘Sec’ in DevSecOps

    Despite its reputation as slow and complex, PAM can be included in the DevOps pipeline effectively

    The introduction of DevOps practices has led to a revolution in software development. However, as companies adopt these new technologies, tools and methodologies, incorporating privileged access management (PAM) becomes increasingly complex. Nonetheless, corporate policies, industry standards and government regulations mandate that security and operations teams must manage and audit permissions and credentials for a growing number of user and service accounts. As a best practice, a least privilege access control model is a must.

    Compounding the issue is that traditional methods of securing developer environments involve manual interventions and restrictive controls that significantly hamper the agility of development and operations teams. Because of that, DevOps has eschewed PAM as too slow and complex to deploy and manage.

    Adding to the complexity, applications, virtual machines, services and workloads running in the cloud all have identities. In fact, non-human identities nowadays represent most “users” in many organizations. This proliferation of non-human identities exacerbates the difficulty of achieving least privilege.

    Like human identities, access for these identities must be strictly monitored and controlled so that unauthorized, unverified access is automatically denied. PAM solutions that support modern application-to-application password management (AAPM) approaches can achieve this. DevOps owners can take control of privileged access without impacting agility, leaving them to focus on what they do best while finally putting the “Sec” into DevSecOps.

    AAPM eliminates the need to store credentials in clear text in the application. Instead, developers introduce API calls in their code to access a vault programmatically and to check out the password. The password is stored in application memory and not written to disk. Once the application terminates, the memory is deallocated and the password is gone, leaving nothing for a threat actor to find. Using this approach, the vault secures the credentials and controls access to them. The vault can also automatically rotate passwords, making them more challenging to crack. Since dependent applications now make API calls to fetch them, DevOps teams are no longer concerned with updating their code whenever the passwords change.

    PAM and DevOps: AAPM in Action

    This is a fundamental approach to AAPM. Other options exist, however, distinguished by increasing levels of cyber-risk mitigation and operational efficiencies:

    Level 1: AAPM to Retrieve a Vaulted ID and Password

    As described, this is the traditional approach to PAM. While vaulting the passwords provides an extra layer of security by removing them from code, passwords remain the weakest form of authentication. Even with automatic password rotation, they persist until the next scheduled rotation (often days or weeks), giving an attacker ample time to attempt to crack. To check them out of the vault, each workload needs a service account. This can quickly amount to hundreds, if not thousands, of additional accounts, increasing administrative overhead and increasing the attack surface.

    Level 2: AAPM to Retrieve a Vaulted ID and SSH Key

    Human administrators and workloads present an added risk to organizations through the widespread use of shared privileged accounts for authentication. Secure Shell (SSH) keys are frequently implemented as a safer alternative, allowing the workload to check out a vaulted SSH key instead of checking out a vaulted password.

    The use of SSH keys includes similar risks and benefits to vaulted passwords. They’re also static, relying on a scheduled rotation. They, too, can be shared among developers and between workloads. Developers and IT admins are often given enough rights to create SSH keys at will without any oversight or central management. This makes them difficult to track and know how they’re being used, by whom and for what. If they’re lost or if a developer leaves, system and service availability can be impacted.

    On the positive side, however, the SSH protocol employs public-key cryptography. The SSH keys (public and private) are longer and more complex than any password. Unlike passwords, they’re not sent over the wire. All this makes them more difficult to compromise and, thus, more secure.

    That said, each workload still needs a service account to authenticate to the vault and check out an SSH key, each of which is a potential vector of attack.

    Level 3: AAPM to Retrieve Ephemeral Tokens

    Ephemeral tokens (e.g., OAuth2) can be created automatically by the vault on-demand and offer a modern form of secure access that is temporary, time-based and expires automatically. This releases DevOps from dealing with installation, configuration and rotation issues while contributing to a best-practice “just-in-time” access control approach. As with the earlier methods, however, each workload still needs a service account to authenticate to the vault to obtain a token.

    Although such tokens can persist, they’re generally short-lived for the duration of a session or transaction, greatly reducing the window of opportunity for a threat actor. 

    Level 4: AAPM Using Delegated Machine Credentials and an Ephemeral Token

    The prior methods are all characterized by a per-workload service account requirement. With a Delegated Machine Credential approach, a service account is only required per-machine.

    When the machine is enrolled in the PAM service, it establishes a mutual trust relationship. The PAM service creates a unique Delegated Machine Credential, machine identity and service account for that machine. Local workloads can then piggy-back off that machine identity, leveraging the delegated machine credential to authenticate to the vault, exchanging it for an OAUth2 bearer token it can use for subsequent API calls (e.g., to check out a password or obtain a token.) Since not all workloads are equal, OAuth scoping can limit which APIs each workload is allowed to access. Thus, by using a Delegated Machine Credential, the number of service accounts is reduced to practically zero, closing thousands of potential vulnerabilities.

    This approach also addresses the lack of desire to introduce PAM into DevOps, as I highlighted right at the start. This method can be fully automated and inserted naturally into the CI/CD pipeline.

    All these approaches give organizations more choice, based on their existing PAM maturity, risk tolerance, and compliance pressures. They ultimately allow DevOps teams to automate, simplify and centralize PAM security management while improving the organization’s security posture, without sacrificing agility.

  • Snyk Brings AI to DevSecOps

    Snyk Brings AI to DevSecOps

    Snyk today at its SnykCon 2020 conference announced a static application security testing (SAST) dubbed Snyk Code that incorporates an interpretable machine learning semantic code analysis engine the company gained through its acquisition of DeepCode earlier this year.

    The company also announced it has extended its alliance with Docker Inc. to become the exclusive provider of security insights for both Docker Official Images and future content certification programs from Docker. Available via Docker Hub, Docker Official Images are a collection of 166 curated container images that developers frequently reuse.

    At the same time, Snyk today announced it has integrated its vulnerability database with the IT monitoring service provided by Datadog as well as the IBM Cloud service.

    Snyk President Guy Podjardny said Snyk Code is aimed specifically at developers as part of an effort to advance the adoption of best DevSecOps practices. It provides visibility into application source code, open source libraries, container infrastructure and infrastructure as code to enable developers to better secure applications as they are being built.

    The company claims Snyk Code is up to 50 times faster than traditional SAST solutions, which would represent a major boost in productivity for developers who often don’t have the patience required to scan code as much as IT security teams would prefer.

    Snyk Code also curates machine learning models using the company’s curated vulnerability database to significantly reduce false positives. It also automatically models application programming interfaces (APIs) based on the best practices observed by the platform.

    Snyk Code is also designed to be integrated with CI/CD platforms to streamline DevSecOps workflows.

    Podjardny said Snyk went beyond simply productizing the Deep Code tool to incorporate capabilities that would specifically appeal to developers rather than cybersecurity teams. Given the volume of code that needs to be scanned before and after code is deployed in a production environment, Podjardny said it’s apparent that DevSecOps isn’t going to be achieved without augmenting developers with artificial intelligence (AI) tools.

    It’s not clear at what rate responsibility for IT security is shifting left toward developers. Beyond simply providing developers with the tools required to analyze code, workflows that DevOps and cybersecurity teams currently rely on must be better integrated. That’s a challenge, because the current rate at which DevOps teams are updating applications typically exceeds the ability of a limited team of cybersecurity professionals to keep pace. The days when cybersecurity teams could have weeks to review an application before being deployed are all but over.

    It may take a while for DevOps teams to gain confidence in AI tools. However, it’s clearly not feasible for human developers to identify every potential vulnerability within thousands of lines of code running on multiple platforms that can have any number of vulnerabilities which developers are not likely to know much about. As such, it’s not so much a question of if AI will play a major role in enabling DevSecOps as much as when.

  • Accelerate Your Digital Transformation with IBM

    Accelerate Your Digital Transformation with IBM

    DevOps practices, processes and solutions help businesses accelerate their digital transformation by improving the speed and quality of software development. DevOps tools enable teams to do their job more efficiently by embracing automation, increasing agility and building speed, versatility and security into the framework.

    At the IBM DevOps Virtual Summit, attendees will learn how to keep their applications running smoothly with automation and data-driven solutions that can reduce mean time to resolution and explore IBM solutions to help innovate hybrid environments, disrupt cloud native development and transform existing mainframe infrastructures. The free virtual event will take place on Oct. 29 from 10 a.m. to 2 p.m. ET.

    IBM leaders will discuss the benefits of DevSecOps, how to increase business value, SRE best practices and how IBM Cloud software and services can help organizations succeed on their DevOps journey.

    The virtual event will feature four educational sessions from leading DevOps technologists:

    • “Application Modernization Enabling Hybrid Cloud with IBM Z,” by Rosalind Radcliffe, distinguished engineer and chief architect for DevOps at IBM.
    • “The Modern DevOps Manifesto,” by Andrea Crawford, distinguished engineer at IBM.
    • “DevSecOps in a Hybrid Multicloud World,” by Sunil Joshi, executive architect at IBM.
    • “Common Tooling Approaches from Kubernetes to the Mainframe,” by Eric Minick, program director at IBM.

    For more information about the virtual summit or to register, please visit the IBM DevOps Virtual Summit website.

  • ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth has extended its namesake software-as-a-service (SaaS) platform for orchestrating DevSecOps toolchains to include integrations with Scout Suite, Aqua Trivy, Gitlab and BitBucket Server and the configuration management database (CMDB) from ServiceNow.

    The company is also adding application portfolio reports to surface the security policies applied to each application, scan results and progress of remediation work and the ability to customize both alerts and vulnerability data compression parameters, such as rate of compression, name and type of vulnerabilities and libraries.

    Finally, filtering and search tools that can be applied to vulnerability datasets have been added.

    ZeroNorth makes it possible to centrally orchestrate and manage both commercial and open source application security scanning tools via a SaaS application platform.

    Christian J. van den Branden, senior vice president of engineering and product management, said that as DevSecOps processes continue to evolve and mature, most application development teams will employ multiple scanning tools because not every tool discovers every vulnerability. This defense-in-depth approach to vulnerability scanning requires an orchestration tool to integrated multiple scanning tools within a DevOps pipeline, he said.

    That orchestration tool also makes it easier for DevOps teams to prioritize vulnerabilities based on their severity discovered by various static application security testing (SAST) and dynamic application security testing (DAST) tools, noted van den Branden. Tools from vendors such as Qualys, Snyk, Palo Alto Networks, Synopsys and WhiteSource are supported across multiple DevOps platforms.

    In general, van den Branden said a “perfect storm” of security issues is forming in the wake of the COVID-19 pandemic. Organizations are rushing to build and deploy digital business applications that will appeal to end users who increasingly are working from home using largely unsecured networks. Cybercriminals are looking to both compromise applications as they are developed in addition to targeting end users with weak credentials that could be employed to inject malware into applications after they are deployed in a production environment, he said.

    Most IT organizations will clearly need to up their application security game, given the sensitive nature of the digital business processes that need to be protected, he added.

    Ideally, DevOps and cybersecurity teams will meld their workflows to achieve that goal. In many cases, however, DevOps teams will simply extend their existing pipelines to address security issues of their own accord as part of an effort to reduce the number of remediation issues they might need to allocate time to remediate after an application has been deployed in a production environment. That becomes easier to accomplish using a SaaS-based platform to orchestrate DevSecOps processes and pipelines, noted van den Branden.

    Regardless of how IT organizations improve application security time is of the essence. More applications than ever are being deployed across an extended enterprise that now stretches from public clouds to multiple classes of edge computing platforms. Defending that attack surface relying on legacy tools and processes is all but impossible if the code deployed on those platforms is fundamentally insecure.

  • Sonatype Advances Open Source Code Quality, Security

    Sonatype Advances Open Source Code Quality, Security

    Sonatype today launched an Advanced Development Pack service that surfaces dependencies between open source components in a way that makes it easier for developers to know which ones to employ to build the most secure application possible and what components offer the simplest upgrade path.

    Company CTO Brian Fox said the Advanced Development Pack service is an extension to the Nexus Lifecycle platform the company currently makes available to identify vulnerabilities in open source code.

    The Advanced Service Pack was created after studying development and cybersecurity practices across 30,000 software teams that Sonatype was able to analyze in its Maven repository, said Fox. The goal is to eliminate a vicious cycle that emerges as organizations develop applications using components that too often need to be either replaced or updated depending on the security and quality issues uncovered later in the development life cycle. By making it easier to identify the highest-quality modules available, the Advanced Development Pack serves to increase developer confidence in the quality of the open source components being pulled as they develop their application.

    A Component Chooser tool, currently in beta and slated for availability next year, will also make it possible to employ project hygiene ratings based on security and license compliance as well as identify where else that component may already be in use.

    The Advanced Service Pack makes it possible to evaluate open source components based on factors such as project quality, ease of upgrade and advanced knowledge of abnormal committer behavior, said Fox. Other factors evaluated include the cost of migrating to a newer or safer version of a module and whether it is possible to do so without breaking code, release frequency, the cadence of dependency updates, development team size and popularity.

    The Advanced Development Pack also furthers the adoption of best DevSecOps practices by identifying which dependencies have become vulnerable and have been remediated, as well as suspicious behavior involving project code commits that might be indicative of a malicious injection attack. It also applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injection. In the past 90 days alone, the malicious code detection bots created by Sonatype have discovered 43 new malicious packages including electorn and loadyaml.

    Sonatype has also included a transitive solver capability that provides comprehensive remediation advice for solving both direct and transitive dependencies without violating policies or failing builds.

    Fox said that while there’s a lot of focus these days on making sure individual application components are secure, it’s also become apparent that cybercriminals are now targeting application development platforms as part of an effort to compromise the entire software supply chain. As such, DevOps teams now need to focus on securing both the components they employ and the platforms used to construct their applications.

    In the meantime, there may never be such a thing as absolutely secure open source code. However, it is becoming possible to greatly minimize the risks associated.