devopsy.kinsta.cloud

Tag: devsecops

  • DevSecOps May Be Key to Prevent Data Leaks

    DevSecOps May Be Key to Prevent Data Leaks

    Data leakage has become something of a norm in the digital realm, despite the fact that cybersecurity budgets are growing and more engineers are assigned to these very issues. Nowhere does this seem more true than in the realm of health care, where breaches that expose sensitive patient data are, sadly, a fairly common occurrence. 

    A recent report by Approov illustrates how severe the problem has become. According to Approov’s  All That We Let In research report, many of the mobile healthcare applications in use today are leaking sensitive patient data through APIs, potentially compromising millions of patients. 

    The study tested 30 popular mobile health (mHealth) apps, and the research estimates that some 23 million mHealth users are exposed, at a minimum. The average number of downloads for each app tested was 772,619. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater. Among vulnerabilities detailed in the report:

    • 50% of the records accessed contained names, Social Security numbers, addresses, birthdates, allergies, medications and other sensitive data for patients.
    • 50% of the APIs tested allowed users (medical professionals) to access the pathology, x-rays and clinical results of other patients.
    • 50% of the APIs tested did not authenticate requests with tokens.
    • Of the 30 popular apps tested, 77% contained hardcoded API keys, some of which don’t expire, and 7% contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.

    “Look, let’s point out the pink elephant out in the room,” said Alissa Knight, researcher and author of the report. “There will always be vulnerabilities in code, so long as humans are writing it. Humans are fallible. But, I didn’t expect to find every app I tested would have hard-coded keys and tokens, and all of the APIs to be vulnerable to broken object-level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports and full PHI records in their database. The problem is clearly systemic.”

    The report helps to illustrate a critical point: Sloppy code can lead to data leakage. “These findings are disappointing, but not at all surprising. The fact is, leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients, such as mobile apps, need a new and dedicated security paradigm,” said Approov founder and CEO David Stewart. “Because so few organizations deploy protections for APIs – that ensure only genuine mobile app instances can connect to backend servers – these APIs are an open door for threat actors, and present a real nightmare for vulnerable organizations and their patients.” 

    For organizations deploying apps using a DevOps methodology, it becomes very clear that much more must be done on the cybersecurity side to prevent data leakage. However, the general consensus is that data protection falls under the purview of CISOs and cybersecurity teams in the enterprise. Perhaps there is no better argument for adopting DevSecOps than the data leakage problems caused by insecure code and sloppy APIs. The report echoes that sentiment and offers several recommendations for developers creating and organizations using mobile applications. In other words, organizations should take several key steps to protect their customer data and sensitive resources, including:

    •  Address both app security and API security: Recognize that synthetic traffic to the API is an issue, and arises from bots and automated tools, not from genuine apps and legitimate data requests.
    • Shift left and shield right: Secure the development process and harden apps, but ensure that runtime protection is also in place.
    • Protect against X-in the middle attacks: Certificate pinning is critical, but often left undone because expired certificates can block apps and impact customer experience. However, when done correctly, certificate pinning does not impact either performance or availability.
    • Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with legislative mandates and to sustain data security and privacy.
    • Continuous testing: Penetration testing and static and dynamic code analysis should be performed regularly.

    Interestingly, those recommendations fit squarely into the role that DevSecOps should take in the DevOps process. 

  • DevSecOps Implementation: Patch Management

    DevSecOps Implementation: Patch Management

    Patch management has been a thorn in IT’s side for decades. While it is undeniably necessary for security and stability purposes, the staggering array of patches that are available make managing them effectively nearly a full-time job – or a job better left to users. Few IT professionals want to be the “patch person,” and yet, nearly all IT professionals want their systems protected by the latest patches. No one wants to find out an intrusion was easily preventable via patching. It goes without saying that the SolarWinds attack has left quite a few IT departments scrambling for an alternate solution.

    The world of patch management has gone through several evolutions that we won’t cover in much detail here. Instead, we’ll focus on what’s available, what you should look for and where the market is headed. Suffice it to say that patch management as a practice has grown from an individual applying patches to servers and server apps while employees were encouraged to patch their equipment, to complex systems that manage the patching themselves, with IT oversight. Currently, patch management is often bundled with endpoint management, simply because many of the patches are going to end points (user machines and devices).

    Out of this growth have come several market differentiators that you should be aware of when looking into a way to manage the avalanche of updates the average organization is seeing.

    • Centralized or de-centralized? Increasingly, patch management is run on servers/cloud and pushes changes out to those machines/devices that need them, or agents on each machine manage updating themselves. Which is best for a given organization really varies. If a lot of machines are running at the edge of their capability, an agent running updates in the background might be too much to ask. In that scenario, a server-managed install environment is probably better. Conversely, if a centralized location to run updates from is considered an architectural weakness (because it requires access to the update pushing engine), agents might be the better plan.
    • OS support. We’re way past the days when single-OS solutions were considered useful. List the operating systems used in your environment, and choose a product accordingly. Most products on the market support Windows/Mac/Linux, but there are variances. First off, make certain your chosen product supports all three. Then ask, “Which flavors of Linux?” Make certain the flavors running in-house are supported by the software.
    • App support. There are a lot of applications out there. Which are supported by the tool? How much leeway does the customer have for adding applications by pointing the tool at update locations? Does it support FOSS updates? There are a lot of those too, and which ones matter. Make certain the tools the organization uses are supported or can be added.
    • Many tools will scan machines for update issues. Understand what your chosen tools scan for, and how the scans impact performance on the target machines.
    • Updates are not 100% perfect. There will inevitably be problems. Make certain the tool can roll back changes. Updating 50 core infrastructure machines, only to find, hours or days later, that the update breaks something demands roll-back capability.
    • Inter-relationships. Updating a piece of software can require that another piece of software or a driver be updated, which can demand that UEFI/BIOS be updated. Or the CMOS on a RAID controller. Understand how cascading updates are handled by the tool, and if the cascading updates can be packaged, so that a failure automatically rolls back the updates applied thus far.
    • Approvals. Speaking of driver and BIOS updates, what tools are available to allow a human to approve changes? No one wants willy-nilly updates to the drivers on core systems – or even to drivers on user systems.
    • Security of the tool itself. We’re in perilous times where IT security is concerned, and frankly, an update command-and-control server is an attacker’s dream machine – take it over, put your back-door update into the mix, and tell it to update every machine it manages. It cannot be understated: an update management tool must be as protected as possible – both by the customer locking down the installation and by the developer making sure the code is solid.

    Once the system is chosen and worked into your DevSecOps environment, updates will be more responsive, which leaves one more thing to consider – does it feed into your agile tools? If the update management tool notifies a project management tool like JIRA when it updates a server, then if code on the server breaks, the developers aren’t in the dark about changes, and will have breadcrumbs to help them track down the source of the problem.

    Imagine if manual updates became a rarity instead of the norm. There is a cost associated with this process, but most of the products on the market can be had for a reasonable price – if you waste a couple hours a month (or for some products, a year) on updating, they’re paying for themselves. Of course, your time is a sunk cost, and the cost of these is an operational cost, so there is an evaluation your organization will have to undertake. Given how busy everyone in DevOps and DevSecOps is, it is likely worth the investment for all but over-staffed organizations. What? There are a few!

    Find what suits your organization, and put it to use. Faster updates, less time investment. The idea is sound, you just need to figure out what suits your needs. And keep rocking it. You are managing updates already, this is just a way to make your life easier. And we could all use a bit of easier in a busy, complex IT environment.

  • ZeroNorth Adds Analytics App to Advance DevSecOps

    ZeroNorth Adds Analytics App to Advance DevSecOps

    ZeroNorth today added an Advanced AppSec Risk Analytics module to its platform for orchestrating DevSecOps processes.

    John Worrall, ZeroNorth CEO, said the analytics tool pulls vulnerability data generated by a variety of security tools to provide both DevOps and cybersecurity professionals with a single source of truth for assessing security within an application environment.

    The ZeroNorth platform is designed to enable IT organizations to orchestrate multiple vulnerability scanning tools within the context of a larger DevSecOps workflow, and can apply analytics to a large pool of security data. That data can be viewed in the context of specific groups, such as a business unit or specific application development and deployment team, or within the context of whichever application generates the most revenue for the business, Worral said.

    Additionally, the Advanced AppSec Risk Analytics module will surface types of vulnerabilities detected and the vulnerabilities most encountered, ranked by criticality, along with other trends in types and number of vulnerabilities detected/remediated, such as the number and criticality of vulnerability findings per specific scanner. It also tracks the applications and entities scanned, number of vulnerabilities detected per application/entity and the applications/entities that have the highest risk.

    ZeroNorth

    Armed with that analytics data, Worral said it becomes easier for IT teams to prioritize and focus their efforts, in addition to identifying areas of the business that may need additional cybersecurity resources and training. IT leaders can also get a snapshot view of the top application security risks to better assess the organization’s overall security posture, Worral noted.

    The Advanced AppSec Risk Analytics module will also surface vulnerability remediation bottlenecks spanning multiple applications within the context of a software development life cycle (SDLC), Worral added. Longer term, Worral said the data collected by the ZeroNorth analytics application will also create an opportunity for the company to apply machine learning algorithms to DevSecOps.

    In general, Worral said the only viable path toward achieving DevSecOps is to foster more collaboration between developers and cybersecurity teams. Getting those teams on the same page in terms of the security data that needs to be analyzed is a crucial first step, Worral said.

    It’s still early on in the adoption of DevSecOps best practices within organizations, however, it’s apparent a lack of cohesion between software developers and cybersecurity teams about which vulnerabilities to prioritize is a major source of dysfunction. Cybersecurity teams tend to create long lists of vulnerabilities discovered within applications without providing much context. Developers are then left to weigh, on their own, when to address a vulnerability versus focusing on writing additional code needed to make an application delivery deadline. Developers take potential vulnerabilities seriously, but there are only so many hours in a day to write code.

    Unfairly or not, developers are being held more accountable for application security. The challenge – and the opportunity – is to find a way to make the entire DevSecOps workflow a whole lot less contentious by helping DevOps and DevSecOps teams more aware of which tasks should be prioritized when.

  • Survey Shows DevSecOps Progress in Larger Organizations

    Survey Shows DevSecOps Progress in Larger Organizations

    A survey of 250 U.S. and UK large enterprises with more $1 billion in revenue conducted by Security Compass, a provider of a platform for automating security tasks as application are developed, finds three-quarters (75%) have implemented DevSecOps processes on current application development projects.

    Rohit Sethi, CEO, Security Compass, said the State of DevSecOps Report published today makes it clear more organizations are starting to embrace security by design as they develop their applications. Nearly three-quarters of respondents (73%) said their organizations follow a “by design” approach that enables them to proactively address cybersecurity and regulatory compliance.

    The primary reasons respondents cited for embracing DevSecOps best practices were to improve security, quality and/or resilience (54%), followed by the ability to bring applications to market faster (30%). One of the misconceptions about DevSecOps is that it slows down application development and deployment. However, Sethi said, in practice, DevSecOps enables organizations to address security and compliance issues that would otherwise result in an application not being promoted into a production environment. Almost three-quarters of respondents (73%) noted that manual security and compliance processes slow down code releases. A full 96% said their organization would benefit from the automation of security and compliance processes.

    The biggest DevSecOps obstacles cited by survey respondents included technical challenges (60%), followed by cost (40%), insufficient time (39%), lack of education (38%), lack of skills (36%) and organizational inertia (35%).

    In terms of deploying applications, the biggest reasons cited by the 51 C-suite executives that participated in the survey were insufficient automation and lack of tooling, at 51% each. Organizational barriers came in a close third (50%).

    In the longer term, Sethi said it’s clear most organizations are shifting toward zero-trust architectures to make their application environments more secure. However, achieving that goal across a broad application portfolio will require more investment in both automation and, eventually, various forms of artificial intelligence (AI), said Sethi.

    It’s not clear to what degree smaller organizations will have the tools and resources required to fund adoption of the automation platforms needed to advance DevSecOps more broadly. There’s more awareness of DevSecOps than ever. The challenge is the tools and processes required to achieve it are not uniformly being pushed into the hands of the individual developer. In some cases, organizational leaders are encouraging developers to embrace DevSecOps without any practical guidance.

    Eventually, of course, every organization will embrace DevSecOps best practices, but the real question is, at what rate? The number of applications organizations are rolling out continues to accelerate, but reliance on DevSecOps best practices to ensure security and compliance remains uneven, at best. Larger organizations that have the resources required to fund these initiatives tend to be further along in their adoption journey. However, there is no correlation between organizational size and the ability to build and deploy secure applications. After all, a smaller organization may make up for what they lack in resources with a greater commitment to DevSecOps best practices.

  • BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket today announced general availability of a community edition of a tool that employs machine learning algorithms to discover passwords, tokens and other security vulnerabilities in code.

    Prakash Linga, BluBracket’s CEO, said application secrets stored in code enable cybercriminals to compromise applications in ways that can impact an entire software supply chain. The community edition of the company’s namesake tool scans commits to determine if any new risks were introduced, and will then block the staged files from being committed. It works with any continuous integration/continuous delivery (CI/CD) platform or integrated development environment (IDE) that supports pre-commit hooks, including VSCode, Jetbrains IntelliJ and PyCharm.

    Developers are then presented with a risk score based on the number of secrets discovered in their code. For example, an active token for Amazon Web Services (AWS) would receive a high score, while a a password in a test environment would be rated low.

    The Community Edition of BluBracket can be accessed via GitHub. The free version of BluBracket can be employed to scan up to 10 repositories and sharing reports in real-time, covering more than 50 types of secrets that might be employed using any programming language.

    Linga said BluBracket also cuts down on false positives by combining machine learning algorithms with a built-in rules engine. In contrast to open source tools, BlueBracket generates far fewer false positives, said Linga.

    Linga said the Community Edition is intended to help foster adoption of DevSecOps best practices among individual developers, in hopes that when those developers are hired, their organizations eventually license the full instance of BluBracket. The company views its tools as being complementary to both tools that surface vulnerabilities in code as well as secrets management platforms, which are often not employed as widely within an organization, Linga said.

    In the wake of recent high-profile breaches that embedded malware in widely-distributed applications, there’s increased focus on securing software supply chains. In some of those instances, Linga said, it’s probable cybercriminals discovered passwords and other secrets that were inadvertently exposed in code.

    However those breaches were enabled, it is apparent cybercriminals are becoming more adept at exploiting a weakness in one application to inflict maximum damage across an entire environment. It’s hard to say exactly what role secrets discovery is playing, but cybercriminals tend to prefer the path of least resistance when it comes to exploiting application vulnerabilities.

    Of course, the hope is that adoption of DevSecOps best processes will reduce the number of breaches by shifting responsibility for cybersecurity further left toward developers. However, that’s difficult to achieve without finding the simplest way possible of getting the security tools required into the hands of the developers that need them most.

  • DevSecOps Implementation: It’s About the Data

    DevSecOps Implementation: It’s About the Data

    It seems we are constantly barraged with, “So-and-so announced that their systems had been breached and 80,000 user records were stolen,” notices. In fact, https://haveibeenpwned.com/ lists ten billion hacked accounts.

    That is no surprise. Databases exist to pool related data together. Even NoSQL type databases, which some saw as an opportunity for wildly disparate data to be gathered and analyzed, almost exclusively contain related data sets. We generally don’t want or need to correlate, say, the number of pirates in the world with annual global temperatures, for example.

    One would think, with decades of experience under our belts, we would have a good solution for protecting that data. If it was a simple problem, we would. It is not.

    Databases are the primary target of most attackers. After all, getting access to your user database gives them account names through which they can try and gain elevated privileges. Getting a large amount of user/credit card information gives them a revenue stream by selling them off (though it is now so common that prices on the black market have become depressed, and this isn’t really profitable, given the risk versus the reward, anymore).

    And databases must, by definition, have broad access. A database does not exist in a vacuum; it exists to serve an app. For server-based databases, it almost always exists to serve multiple apps. It must be on the corporate network (even if that network is a virtual private cloud), and it must … offer up data. It has users that have greater privileges than your average customer, and is notoriously difficult to protect with strong protections like encryption.

    Encryption poses problems at multiple levels. It is still a bit slow, for starters. This is the nature of the beast – if it takes X microseconds to respond to a request, encrypted data will take at a minimum X+decrypt time (regardless of where decryption occurs). If encryption is done by column, index fields cannot be encrypted (because “nZ19?SDF” is unlikely to be in the same sort order as “ford explorer”, for example) Which means some data is immediately excepted from encryption. If encryption is handled by the database system, then the time overhead exists, and the database system must send the resulting data over your network … unencrypted. I was involved in a couple of projects that required encrypted databases – the one I can vaguely talk about was putting information about your corporate network onto Android and Apple devices. Needless to say, since phones and tablets are misplaced quite often, and most have weaker security than your average laptop, we needed information about critical infrastructure to be encrypted. It was … painful. We only managed it successfully because corporate networks are finite resources, so the amount of data we needed to store was limited, and we could prove performance wasn’t going to be the issue.

    So what can you do? Continue to follow attempts to adequately encrypt corporate databases. Eventually, someone will crack this problem in a way that is performant, can be debugged and reliably protects the data.

    Until then, protect your databases. Use the tools we’ve talked about in this series to monitor and protect the entire network, knowing that the database is a high-profile target if someone gets in. And use the other security tools available. The major database vendors offer DBMS security tools to evaluate your current status. Some will flag weak passwords, others will monitor for injection attacks (as will development tools discussed in the first few installments of this series). Lock down interfaces to databases – by user, by IP, whatever makes the most secure, but still usable, environment for you. Set up monitors for behavior outside the bounds of normal behavior – a query of 250K records should raise a flag, for example, since the vast majority of apps will only do a subset that can be paginated. Sure, it will probably be a false positive caused by someone hand querying, but the one time it isn’t, you’ll be glad the monitor was there.

    And protect your database backups – be they actual backups or a dump to test. Fewer organizations are using real, unfiltered data for testing, but it crops up in most orgs at one point or another, as testers are trying to look at issues that fake/masked data can’t replicate. For actual backups, those must be encrypted. To lose your customers to a hacker because you had an unencrypted database dump lying around, and the attacker didn’t even have to attack the DB, is downright shameful, and happens too often. Along these same lines, and this should go without saying, but it’s happened enough that I feel compelled,  do not copy large chunks of your database out to an unsecured cloud storage bucket. Some vendors have addressed this issue by not allowing public unsecured buckets, but you can still do this, depending on the cloud you are using. So, don’t.

    The database security market will be best served by being rolled into SIEM and/or XDR. And while I’m in full-on pundit mode, for this statement, I’ll predict that is where it is headed. Database security is as much about overall security as it is the database, so overarching systems are the best place to detect and defend from. So watch for moves in that direction. A holistic view will serve you better in the long run.

    Meanwhile? Keep rocking it. Treat your data like gold, because to hackers, it really is. And, keep running the world’s business. Celebrate your successes as much – or more – than you learn from your failures.

  • Tidelift Secures Open Source Software Supply Chains

    Tidelift Secures Open Source Software Supply Chains

    Tidelift today announced the general availability of a platform dubbed Tidelift catalogs, through which enterprise IT organizations can more effectively manage their open source supply chains.

    Donald Fischer, Tidelift’s CEO, says the Tidelift catalogs platform enables IT teams to curate, track and manage open source components that have been vetted and adhere to compliance requirements by Tidelift. The company is working directly with the maintainers of those open source projects to compensate them for making that additional effort, said Fischer.

    Developers can reliably pull components spanning common language frameworks like JavaScript, Python, Java, Ruby, PHP, .NET and Rust, with more programming environments to follow, added Fischer. Those components are made available via a Tidelift Subscription service.

    Fischer said Tidelift is going beyond merely scanning open source components for vulnerabilities. The company is ensuring that when developers access versions of open source components, those versions comply with specific sets of policies, said Fischer. As a part of that subscription service, Tidelift monitors components for vulnerabilities as they are discovered, and works with maintainers to implement updates as needed.

    While many organizations are starting to employ DevSecOps best processes, Fischer said the discovery of an issue involving open source components often comes far too late in the process. The Tidelift catalog approach ensures there are no last-minute surprise that are only discovered just before an application is about to be deployed in a production environment.

    Securing software supply chains has become a higher priority since it was revealed that cybercriminals successfully inserted malware into an application update made to network monitoring software provided by SolarWinds. That malware subsequently rippled across IT environments involving multiple corporate entities, as well as several Federal agencies.

    Of course, securing a software supply chain doesn’t happen overnight. Most IT organizations don’t have the processes and platforms required to vet open source components and frameworks. Tidelift is betting most of those organizations would prefer to subscribe to a service, rather than set up that infrastructure themselves. However, for organizations that require in-house monitoring of all the elements of their application development platform, Tidelift will make an on-premises edition of its platform available.

    As organizations become more dependent on software, the potential impact malware can have on their operations can be extensive. Organizations of all sizes should expect to be fielding inquiries from customers, suppliers and partners concerning the level of rigor being applied to their software development processes. In effect, they are going to demand to know the provenance of the software they are being asked to implicitly trust. In many cases, those inquiries will provide the incentive to accelerate adoption of DevScOps best practices.

    The days when organizations blindly used software with little regard to its origins are coming to a close. That doesn’t mean reliance on open source software is necessarily going to decline; however, it does mean application development teams will be held more accountable for the open source components they rely on.

  • A Pragmatic Approach to DevSecOps

    A Pragmatic Approach to DevSecOps

    In response to market and competitive forces, many companies are using DevSecOps to develop higher quality and more secure software. Whether that software is their own product or is a component of their product, quality – and especially security – have become required rather than optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can, and has, caused significant disruption.

    Barriers to DevSecOps Adoption

    The main barrier to the transition from DevOps to DevSecOps is organizational rather than technical. Many companies are already employing special security teams tasked with ensuring applications are secure and that policies are being followed. However, they tend to act as gatekeepers to the release process – nothing gets released without security testing. This approach is prone to be “too little, too late,” as the security team is usually involved near the end of the development life cycle. Attempts to “test in” security rarely succeeds. Security needs to be built in from the start; “shifted left” so that security is fully integrated into the process from the start. Let’s break down these barriers:

    • Lack of motivation and awareness:  There’s a lack of awareness about security issues, and about the risks and impacts security vulnerabilities pose to the organization in terms of liability and reputation. Vulnerability statistics make it clear that many companies are still not taking security seriously enough. This indifference remains, even when 63% of companies had, or nearly had, vital data breaches in 2019 and each breach cost an average of $3.9 million to deal with.
    • Distrust: Lack of trust between teams is expected in most organizations, but it’s particularly problematic between software developers and security teams. Developers view security as impeding their success, and security teams view developers as incapable of delivering secure software.
    • Poor Perception: The prevailing view of security is that it’s difficult to implement and somebody else’s problem. If security teams are solely responsible for security, then it’s easy for developers to delegate to them. Companies often think that security can be tested into the product at the end of development – with disastrous results. Vulnerabilities discovered at this late stage are more difficult to debug, with subsequent impacts on time-to-market, budgets, product quality and reputation.
    • Gatekeeping: The security team sometimes acts as gatekeepers of release candidates, which is a source of friction between developers, testers and security experts. Placing security as a last, QA-like step before delivering a release is too little, too late. Developers also don’t like other teams imposing restrictions on their work, which is an issue when trying to put security controls, like secure coding practices, in place.
    • Lack of integration: Without integrating security practices and tools through the entire development process, security improvement initiatives have trouble getting off the ground. In fact, the key tenet of DevSecOps is to integrate security practices into each phase of development.

    These barriers might seem daunting, but it’s not unlike other corporate cultural shifts. Security teams need to delegate aspects of security to development teams and integrate secure practices as early as they can in their work. Developers need training and understanding of how critical security is to their work. Developers already have an appreciation for safety and quality, but lack some of the basics of good security practices.

    It doesn’t need to be this way. However, removing these barriers won’t happen overnight, so a practical and gradual approach to improving security is needed.

    Easing Your Way into DevSecOps

    Transitioning to a more secure software development process across an organization rarely works when done with a “big bang” approach. There’s often lack of buy-in from the teams, and general resistance to change when new approaches haven’t proven themselves. The cultural barriers to adoption remain, and the initiative fails. As with any large task, it makes sense to start small; to learn and adapt before expanding to more teams. The move from DevOps to DevSecOps should be organic.

    Start Small

    The alternative to the doomed “big bang” approach is to start with a small, motivated team, where it’s possible to implement new practices from the very beginning of a project. By keeping the scope, and thus, the technical and business risk, of the project smaller, it is possible to allow time for learning and adjustments along the way. Think of this as an incubator project, where the results are analyzed and used to evaluate gains, losses, what went right and what went wrong. This team can learn, and then teach the larger organization what works and what doesn’t. Importantly, they set the standard for how to approach DevSecOps, and kick off the organic growth needed for a smoother transition.

    Starting small extends to the use of new tools, as well. It’s one thing for a small team to adopt new technologies, but they can be quickly overwhelmed. Static application security testing (SAST) tools can produce a lot of information. It’s important that initial projects concentrate on high impact, high probability vulnerabilities, first and foremost. It’s easy to get bogged down in the details, and discipline is needed to focus on the highest impact, and to get the most ROI out of new tools.

    Start at the Beginning (Or as Early as you Can)

    This is where “shift left” plays an important role in the transition to DevSecOps. A small team can introduce new techniques without a large initial impact on productivity. They can also start integrating security from the beginning, right at the concept phase of development. They can introduce new tools, and become proficient at using them. It’s at these early stages where the payoff is the greatest. Finding and fixing possible vulnerabilities, and adopting more secure design and coding practices, greatly reduces the downstream impact. It’s not hard to justify the effort, when security attacks and data breaches in production systems can cost millions in fixes, downtime and reputation.

    Measure Success

    The interesting thing about measuring DevSecOps success is looking at what isn’t there; security vulnerabilities and potential software weaknesses. To understand how well a new DevSecOps transition is working, it’s important to have a baseline of vulnerabilities that exist in your other applications. For example, how many vulnerabilities were discovered during security testing? How many vulnerabilities made it into shipping products? If these statistics are known, then it’s a case of measuring how well the new project does versus the baseline performance.

    Other metrics are important, too, such as measuring the number of vulnerabilities detected, identifying those that are true risks and those that were removed through corrective action. SAST tools provide information on a per-build basis, so it is possible to look at trends over time. You can evaluate the DevSecOps process in terms of vulnerability trends over time; are they converging to a goal? How quickly is the convergence?

    The ultimate measurement of success is a more secure product and, ideally, security testing at the later stages of development should find fewer vulnerabilities than in the past. After building in security and starting at the beginning with a shift-left approach, vulnerabilities are caught sooner and removed more quickly.

    Start your DevSecOps Transition

    The critical time to detect new security vulnerabilities is as soon as developers write new code (or test cases) before it’s submitted to a build or software control system. It’s also critical that tools work in your favorite development environment (be that VI, Emacs, Microsoft VS Code or Visual Studio, or any of a number of Eclipse-based environments). It’s at this point where SAST tools shift security improvement via automation to the earliest point in the development cycle. Finding and fixing vulnerabilities here is less risky, cheaper and easier.

    Equally critical is establishing an initial baseline inventory of your third-party software assets, whether that is open source, reused internal code from other projects and/or third-party commercial software. This is done at the very beginning of the project, about as shift left as it gets! Software composition analysis (SCA) is critical throughout the development process since the open source and third-party software that you depend on is likely to have updates and introduce new security threats over time (including after you release the product).

    Early adoption of SAST and SCA tools can have many benefits as part of your DevSecOps adoption. These tools used in conjunction with a security “built in” approach make this transition easier:

    • Improve security awareness by exposing vulnerabilities in existing code, third party software and newly developed code. SAST tools provide all the necessary information to fix potential vulnerabilities, but also provide an explanation of the severity and risk. Developers get more experience with the types of software weaknesses that lead to vulnerabilities, and learn to avoid them.
    • Illustrate ROI by measuring success, and have a goal in mind. Eliminating just one serious vulnerability justifies much of the investment. However, communicating this ROI is important, and needs to be put in the proper context of how costly and risky vulnerabilities are once a product is released.
    • Remove gatekeeping so that developers and the security team are working together. Security teams provide the security controls that developers need to follow with a “trust, then check” approach. Developers learn more about secure practices over time, and integrate that knowledge into their existing workflow. In the end, there is no security team gate at release, and all members of the team know and understand the state of the product.
    • Integrate security practices into software development gradually, starting with a small team and small project. As experience is gained, these teams train the rest of the organization on best practices.

    DevSecOps From the Ground Up

    DevSecOps is a way to build security into an application, and the transition from an existing CI/CD and DevOps process is made easier with the right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. A “start small and start early” approach is recommended where new techniques, processes and tools, such as SAST and SCA, can be integrated with less downtime and cost.

    Most importantly, you need to decide what the success factors are. Measuring success and the ROI of the effort is needed to grow DevSecOps organically within the organization. Tools and automation provide the data needed to show progress, but communicating the ROI needs to be done in business terms. In the end, success results in a more secure product, and reduces your company’s exposure to data breaches and cyberattacks.

  • DevSecOps Implementation: SIEM

    DevSecOps Implementation: SIEM

    The world is filled with events. Our inbox floods with events that marketers really want us to pay attention to, while news feeds flood us with events they’re trying to raise above the background noise, but then, the dog barking interrupts our consumption of that information. Our family is, meanwhile, texting us about events on the family level that may be related to events on the national or world stage … meanwhile, social media is full of garbage information about events that may or may not be real, and that you may or may not care about.

    We ignore the vast majority of these inputs and move along with our day. The inputs that require our attention usually, but not always, get it. Sometimes, we fail horribly at filtering, judging importance, or both, and it has life-impacting ramifications.

    This is not too far from the state of security event management when security information and event management (SIEM) was born. Disparate feeds were coming in from all over; analysts – be they dedicated security folks or systems administrators wearing an extra hat – had to guess which of dozens, hundreds or even thousands of events were a real threat to the environment.

    The first step to gaining control of that environment was standardization and aggregation. Get the events into one place, with similar information available for similar events. That was where SIEM came from.

    Since then, the number of events coming in has continued to rise. Companies that were seeing hundreds of events a day are now seeing hundreds an hour, and SIEM vendors had to keep up. The complexity of attacks, and the ability to detect them, has gone up, and SIEM vendors have had to keep up. Tools available for feeding the SIEM and for acting on the aggregated data have evolved … and SIEM vendors had to keep up.

    At this point in time, SIEM is best characterized as a data aggregation platform with limited intelligence that aids in filtering of irrelevant events. It’s akin to turning off social media and telling those close to you to call if needed; it filters out the worst noise and elevates the most important messages.

    Other tools can analyze their own data and make their own deductions, but SIEM is where you bundle all security-related events in one place, so it is the logical place to filter the noise and raise awareness. But it requires a high-volume, adaptable datastore. Vendors have reached that plateau.

    Once volume issues were mastered, SIEM vendors turned to helping filter the insane volume of security event noise. Yes, it is a security event if Bob logged in on a new workstation, but it probably isn’t a noteworthy security event. Unless Bob’s new workstation is in a country where the company doesn’t do business, or Bob is still logged in on his own workstation, blissfully unaware of the other login.

    So, rudimentary filters were applied to the event data in the SIEM. This got rid of a huge amount of noise. Next came filtering events that, logically, looked like notable security events, but just weren’t. Something was scanning ports on the firewall. An internal firewall. Sounds bad, unless the security tools’ logs showed that an authorized user kicked off the scan. Then, it’s a simple matter of asking the user in question, “Are you scanning X?” and moving along. It’d be better for the system to lower the importance of the event based on the fact that it is an authorized user doing the scanning, with corporate-approved tools. Then, an analyst may not need to get involved at all (my security friends are cringing because, literally, they trust no one, and would point out that authorized users can misuse tools, too – so I’ll note that here).

    But the event volume kept going up, and the analysts were even more swamped. Between adding new reporting apps (HIPS alone can add thousands of reporting points to a SIEM), and increases in events on existing monitored points, it was ugly.

    Enter AI. This is when machine learning (ML) started becoming the norm in SIEM. Now, we want the system to avoid using hard-and-fast rules that must be maintained, but to use knowledge it gains by watching the flow of data and an analyst’s resolution to selectively raise/lower the priority of events. Now, the events that actually bubble up to analysts are ones that the ML engine sees as fishy, and the number is greatly reduced. False positives still occur, but not nearly at the volume they did before, as the system learns how to detect them.

    But wait! There’s more!

    All that data in one place with ML engines crawling over it was just too much temptation for data scientists and deeply knowledgeable security personnel. So, the ability to plot a course through seemingly unconnected security events and determine that this or that was actually evidence of intruder or attacker activity spread across the system came next. This is where we are now – the ability to connect the dots on events that analysts (or the system) might have filtered out to find patterns that indicate intrusions.

    But it comes with a price. It’s not cheap to set up, it’s not easy to train, and maintenance of a system that takes inputs from everywhere and tries to correlate the resulting dataset is … work. We’re not talking a little bit of data here, and, like the environment it comes from, we’re not talking a little bit of complexity. Do you need it? I would say yes. Even if you only use SIEM as a big data store, it will help you perform post mortems when (not if) you have a breach. It is worth the effort, unless you are tiny or have no Internet presence to speak of.

    Keep rocking it! SEIM is another tool to consider as you move to DevSecOps dominance, but again, just a tool that requires you to keep the org safe.

  • Approaching Security as a Fundamental Element of Software Development

    Approaching Security as a Fundamental Element of Software Development

    How we really integrate security into the SDLC? What are some of the best practices around secure software?

    In this episode of TechStrong TV, Jill Britton, director of compliance, and Stuart Foster, product manager at Perforce, joined us to discuss how to improve application security by making security a fundamental component of the software creation process.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined buy a couple of folks that I’ve talked with before on a webinar and a few other videos. Jill Britton and Stuart Foster from Perforce. Welcome to you both.

    Stuart Foster: Thanks for having us, Mitch. 

    Jill Britton: Thanks.

    Ashley: Let’s start off with some introductions. Since you’re ahead in the time zone here, Jill, how about you go first?

    Britton: Okay, thanks. I’m Jill Britton. I’m the director of compliance for static analysis tools here at Perforce. I look after areas regarding coding standards, functional safety standards, security standards, anything in that area.

    Ashley: Excellent. Stuart, you want to introduce yourself? Tell us about Perforce, too. 

    Foster: Sure, yeah. I’m Stuart Foster. I’m a product manager for our static analysis products, both Klocwork and Helix QAC. And a little bit about Perforce, we help with enterprise development and DevOps at scale. We have a lot of various tools that help accelerate development projects in terms of your planning. So we have project and portfolio management tools, requirements management tools. We have things that help in the create area of the DevOps infinity circle for issue management version, asset management, code review. We have static analysis. We have various functional test case management and things like that that also fit in the verify. And we have a lot of tools that are here to drive your product at a high quality to market. 

    Ashley: Excellent. Excellent. Well, very timely conversation at least here in the U.S. with security of software, in this case distribution with the SolarWinds situation. We’re not going to be talking about that, but strongly the topic of secure applications is right in there, right at the top of the list. Let’s first start, I know we’re going to get into some coding standards and some things like that to equip people with some things that they can use. Maybe we first start with DevOps is more than just – and shift-left is more than just, okay, let’s start having meetings or talk on Slack with the security people and then suddenly we’ve shifted left. You know, there’s a lot more to how we really integrate security into the process of creating software. Maybe, Stuart, if you want to start sharing some of your thoughts about that and of course, Jill, get your perspective as well. 

    Foster: Sure, yeah. I mean you think about DevOps, you think about agile development and it’s the ownership of code; but outside of simply delivering functional requirements for your products, your applications, you know, a lot of teams are just thinking about security. So there’s a necessary to build that in directly. And what that leads you in to is selecting tools, selecting processes to ensure that you’re kind of baking in the security into your pipelines and making it automatic. That starts with thinking about coding standards and things like that. So there’s plenty of secure coding standards that you can focus down on. I think Jill has a couple of words for that.

    Ashley: I’m sure you do. Go ahead, Jill.

    Britton: Oh, I have many, many words on that. The important thing is that you pick the standard that you are going to be comfortable with, that you are going to be able to apply. If you’re supplying a product to a supplier, you will probably be told which ones to use. But you’ve got I think that cert – oh, where, it’s from Carnegie Mellon University. They’ve been looking at security for many years now and it builds up and it also takes experience from both academia, tools, developers, actually anybody who wishes to contribute and then of course it is looked at all the contributions. So this good security standard because it is there.

    But connected to that you’ve got the Common Weakness Enumeration so administered MITRE, and that is actually just a collection of vulnerabilities that have been seen and proved in the field. So you’ve got this whole wealth of experience and you want to avoid doing what the problems other people have seen. That’s where these kind of standards come in. CWE I would argue isn’t a coding standard. It’s more a measure. You know, have I seen this problem? Have I got this problem? And there’s another related set of numbers, let’s put it that, which is common vulnerabilities and that’s even further down the line. Before you even get to see weaknesses, there are vulnerabilities and you just have to use this information in your own developments. Don’t do what somebody else has already done is kind of the way to look at it in security in particularly. 

    Ashley: It isn’t like we don’t know how to create secure software. We do but we kind of do the same thing over and over, the same mistakes, right? 

    Britton: That’s right. 

    Ashley: Sometimes just out of not knowing and sometimes just human error. Sorry, Stuart, you were going to jump in there too. 

    Foster: I was going to say, so effectively one of those, CWE is effectively describing issues that are not necessarily related directly to a language; and the other ones are specific rules that you follow to ensure that you don’t run in to these types of vulnerabilities or weaknesses, right?

    Britton: That’s right. That’s it.

    Ashley: Yeah, there are specific things that are in Java, PHP, you know specific languages that are very well used, very popular of course. Go ahead, Jill.

    Britton: No, the thing is when you look at the CWEs, they are categorized to languages or to systems or just to general sort of areas; but there are then what they call the lists. So you’ve got a list for C and a list for C++ and there’s a list for Java. Then you also have a top 25. Now a top 25 may or may not apply to your own product, but it’s always worth having a look. If those ones don’t apply, there’s another sort of secondary list. It’s emerging, and you could look there. There’s always something to check against for any sort of software.

    Ashley: Are most of the things on that list you find have been there for a while? SQL injection, buffer overflows, things like that? Or do they tend to be newer things? Are we seeing the same things over or would we find a lot of new things?

    Britton: It’s a variety. You do see the same ones over and over again. There are some weaknesses that were on the 2011 list and are still in the 2020, but there are new vulnerabilities as new types of development come in and you get more skilled hackers really. You’ve always got to consider that the hacker is always one step ahead.

    Foster: And you kind of see that these standards or these top 25 lists, they change after every couple of years and they spend their time kind of reviewing the vulnerabilities that have been found in opensource projects and other places and kind of give them a weighting. So while you may see the top 25 have a pretty similar overlap between multiple years, their rankings change. So it kind of shows to you that in general software is becoming more secure but not as secure in these new areas. So you see some vulnerabilities lower and the new ones come up at a higher rate. I think it also depends on where software development is currently is in terms of market. What’s the new hotness? Is it Internet of Things connected to software? Is there a new language coming out that has never been attacked? So you see the priorities change on these top 25 lists.

    Ashley: Let’s step back for a moment. How would a development team or developer – I assume most folks are probably familiar with at least CBEs or some things like that, but maybe they haven’t dived into the top 25 for CWEs. What’s the best way to do that? Is it just go out and read about them, educate yourself? Do people, do development teams like, okay, I’m gonna dive into this and research a little bit more and I’ll share with you or how do people apply this to their teams?

    Britton: Well, there’s several ways they apply it. Sometimes they just hear about it, something like we’re doing talking today; and they go, oh, is this going to be relevant to me. And look, it’s a few things. As I said, sometimes a supplier specifies the angles to have proof that you’ve checked against this. And of course the static analysis tool, we can map checkers and messages against these vulnerabilities and these weaknesses so that we can show your code is exhibiting these features. But it’s really important to know what you’re going to be looking for and then do something about it as the static analysis tools can show you, yes, you’ve got this vulnerability but really it’s not off point just leaving there. You must do something about it.

    Ashley: You know, it’s interesting. So many, not everyone of course, so many of the vulnerabilities are about input, right, to a user interface of some type, web, OS command, mobile device. It’s a lot about neutralizing, dealing with the input that you’ve received, making sure that they’re not injecting something that they shouldn’t, getting access to a directory, all kinds of things like that. So it’s things that apply across multiple technology stacks and multiple applications. So generally speaking it’s not like this is a skill you’re going to use on one app and then you have to relearn it for the next app. You carry that stuff with you. It’s part of your skillset you build as a software engineer. 

    Britton: Yeah, it’s education, isn’t it? You know, it’s just everybody gets more and more experience of this type of issue. It’s not that long ago that security wasn’t at the heart, but now it is.

    Foster: And if you think about it, you know there’s kind of different levels of maturity in terms of security, right? You start developing because you know you have some types of vulnerabilities and you start working towards that. But if you think more longer term about your projects and how they might be very important IP or pieces of software that are embedded over time, it becomes more important to think about security because, you know, being able to fix some issues that you know about versus following a secure coding standard to ensure that the reliability, the strength and hardening of your software to begin with means that years down the line when somebody has integrated your piece of software into some type of embedded system that can never be touched, then you’re lowering the risk of there being vulnerabilities permanently out in the market for a very, very long time. So that becomes kind of the second level maturity when you’re developing and thinking about developing more secure software.

    Ashley: Now you mentioned, I forgot which one of you mentioned something about you might encounter something under a contract with the customer that requires specific security standards. One example I know that you all deal with quite a bit is ISO 26262 for automotive industry. Here you’re dealing with safety of course as well as security. Talk a little bit about how something – do the industry-specific standards really kind of go off the reservation to do something really different or are they building on what we do generally in software and then applying it to their specific domain?

    Britton: We could take ISO 26262 which is for vehicles. It’s very much good practice. It’s nothing totally off the scale. They recommend for software the use of a coding standard. You are allowed to use any coding standard you like, but then there are specific categories of software violations that you need to be able to detect so whatever you do. MISRA is sort of the classic for 26262 because it was developed for vehicles. But you have other industries with very, very similar requirements from software and now we’re moving into the scale of security. Back to vehicles again, it’s ISO 21434 which isn’t out yet; but that also requires the use of a coding standard and the violations they’re looking for are still very, very similar. It’s the same type of things. Quality software is what we’re always looking for.

    Foster: Because as I kind of mentioned a minute ago, you think about a car, that’s a big rolling embedded system that’s more or less permanent once it’s complete and it’s really hard to fix later. So you can understand how security as an oops, we’ll go back and fix it versus security as a process becomes more important. That’s exactly why ISO 21434 is becoming a thing or will becomes a thing once it’s releases. But we already have customers in industries looking at it and following along and understanding what that impact is going to be because to connect the cars was a big rolling computer.

    Ashley: You know, this is a little bit kind of parallel to just creating software but not too long ago I went through a web trust audit and very much like a standard like you’re describing it is do you have a process, do you have something that you follow, should follow, and do you follow it and do you have evidence of that. So many of the standards are just the technical details of what you should do to write pure code. It’s do you have the processes around that and are you following those and in some cases you do an audit. Necessary if you want a WebTrust, for example, certification or others. So it’s not just writing secure code, it’s if you say you’re going to do it, then you have to do it and demonstrate that you’re doing it and have some form. So what I’m saying is it’s really an investment that you’re making by writing secure code following some of these standards, but then that’s going to help you down the road meet other requirements. 

    Foster: Yeah, it makes it easier when you’re trying to implement say ISO 27001 which is information management security management requirement compliance thing. And there’s controls in there and what you’re talking about per the audit is putting in controls for your business and there are various areas in those controls that in many ways relate to the software that’s developed within the company. So yeah, by following some of these security standards you’re in essence helping with those controls later when/if you go and certify your company as that type of ISO requirement.

    Ashley: You know, Jill, I know you deal a lot with governance and some compliance and things like that. What are some of the best practices around secure software? We’ve touched on quite a few already but are there some other thoughts on other best practices to help people move up that maturity scale?

    Britton: Well, it’s a very basic part of any process really. Choose your metrics. How are you going to actually measure and see how you are progressing through your process? And similarly to software weaknesses, when you get your metrics, what are you going to do with them? There’s no point in collecting a whole collection of them and saying, yep, we’ve got our metrics. What does it mean? Does it mean that we have got 27 security violations last week? Oh, great, we’ve got a number. But what are we going to do about those 27 or so security violations? Again, it’s back to process. What is your process? What is an acceptable level of these metrics? And you can have metrics working all the way through the cycle right from requirements to development and test. You can actually have measures of how you are progressing through your cycle.

    Foster: And also what you find when you look at a lot of these security standards and their vulnerabilities, they have kind of the impact likelihood, cost to remediate, potential issue or risks that you see in the market when one goes out. So alongside that, a lot of the standards as well have kind of a risk scale or a prioritization that helps you – gives you an idea of where to start. And then in terms of the process, it’s not always a matter of running a tool or trying to follow these standards and trying to fix all the bugs. It’s important to start somewhere. What we typically call it is baselining where you kind of know your current quality of your software as it is right now, and the point is to start following a security standard and stopping new vulnerabilities from being introduced, and then you can go back and start working on the prioritization of what to fix to start cleaning up. Right?

    And also when you look at it and it seems insurmountable, you might want to spend some time looking at your past kind of customer weaknesses that were found or bugs that were found and kind of understanding in addition to what the standard is important, looking at what types of vulnerabilities you’ve produced or have reported back and focus there. That’s a good start, you know? You know kind of what your developers’ training weaknesses are and then you can implement kind of teaching, learning, training processes as well to help getting your development team more comfortable, more experienced in dealing with these types of issues. 

    Ashley: Sometimes also building on what you said, it can help bring to light other issues along the process like, for example, we keep getting libraries introduced into code that we don’t realize are there and they show up as a security vulnerability. Okay, well, let’s go fix that part of the process too so we know that those things are there and when updates happen they go through some defined process. Another one might be it’s not just new things we find but also repeats, things we consistently find, occasionally over and over whatever frequency. Okay, if we’re fixing them but how do we stop introducing them? What are good ways to help that? It might be education tools, et cetera. Lots of ways to do that. So to both of your point, to your point too, Jill, don’t ask questions you’re not going to do something about the answer, right? 

    Britton: That’s right. That’s exactly right.

    Ashley: So you have to take action on it and of course that’s ultimately why you’re doing it. You’re not just going through the motions to meet some paper standard because that will catch up with you very quick if you do something like that. 

    Britton: _____. It will. You’re absolutely right.

    Foster: Just buying yourself technical debt and risk.

    Ashley: Yeah, exactly. And it will catch up with you. How do you introduce this to some people words like process, standards, compliance, audits, anything with an ISO in front of it? Those kinds of things just sort of kick up the you’re cramping my style here, right? You’re putting a damper on my ability to be creative and write code. I’m bring a little bit hyperbolic, but not everybody reacts to those things favorably. How do you position this with organization so that it’s not just a dreaded thing we have to do, there’s actually really business value to it and it’s good for you and your career?

    Britton: Well, the whole thing with following a process is the developers can be involved in this process and then go through their careers excel help develop this process. But the process shouldn’t be stifling. It should never stifle the creativity. The whole idea of the process is tell me what you do and how do you prove that’s what you do? Okay, that’s fine. Now maybe how can we tweak it and do a little better? It’s the pro thing of continuous improvement that comes up in all the audits.

    We’re actually ISO 9001 certified. So we’re all going through this on a regular basis. You know, but we’re not trying to stifle our developers. They will say, “Well, okay, we have this process. It’s not quite working for us. Can we make some modifications?” We go, yeah, looks fine. We talk to the necessary people and usually it’s absolutely fine. So we involve the developers all the way through and they will then follow it because it’s their own process. 

    Foster: Yeah, I think the goal is the least amount of friction and introducing it over time. And as Jill said, there’s continuous improvement, right? It’s a long-term goal. It’s not something that’s done once and you get over the big hump of pain and it’s a ton of crunch work. It’s just something that you do over time. You look at agile development, right? People do standups. There’s processes, you know. There’s a level of documentation and planning that isn’t overly annoying. You know, the goal of DevOps is to automate a lot of those finicky processes so that they’re fast, they’re repeatable, they give time back, right? They report information back as quickly as possible so that they can be resolved quickly, right? That’s just lowering the friction, the pain of going back and fixing a feature or some sort of development commit, right? And then you’re just layering on another check layer of security, right? And it should be painless. It should be easy.

    As you mature over time, then the quality is going to get better and that goes back to the metrics that Jill was mentioning, not just having a number but seeing that number go down. And then having your teams be able to see that kind of dashboard or information as a feedback mechanism to say, you know, you can visually see the qualities improving. You know, customer reports of issues from the field are going down because our quality is going up. Why? Not just because of security but because of all the automation and the unit tests and checks that you have written and you’ve made the effort to produce better quality code and it’s going to pay dividends. 

    Ashley: I like the idea of tying it a continuous improvement process whether you label that as quality or other things because you can apply that to your DevOps process, to your tool chain, to the quality of your code, safety, security, making compliance easier for you, just improving your overall how you write software, maybe workflows and things like that. So you can make some of these compliance activities or standards activities really part of just maturing your organization and getting better at what you do, working on the organization as well as in it.

    Question for you, how do things like the privacy laws, you know, GDPR, CCPA for California, do those fall into this realm as well? Do they impact the developers as we’re talking about the use of customers’ information and of course we’re handling that in the applications? Is that something developers need to be that familiar with or is that more of the marketing department that are sending e-mails to people?

    Britton: It’s not greatly down with the developers, but it really depends on the type of data that they’re handling. Looking at the tools that Stuart and I work with, we’re not getting/bringing in external tools because it’s a static analyst tool. So we’re not looking at that. But when you get to things in the field, the developers have to be aware if they are going to be handling personal information and they then do have to have GDPR and that has to be included into any process – how are we going to handle this.

    Foster: Yeah, and there are coding rules that, you know, try to help with these types of things. You know not having hard coded secure passwords, not using magic numbers, various levels of encryption that should be written, or warnings that you’re using an outdated type of like encryption in your software, the ability to handle unvalidated inputs and outputs. Things like that are going to help cover some of the requirements for GDPR. So you need to kind of understand how your system is interacting with other systems and securing your APIs and all things like that. So it’s not just your piece of software at that point. Your developers need to be aware as to how your software is going to be used and implemented and how it’s going to communicate with other pieces of software or systems. 

    Britton: That brings us back to the weaknesses we were discussing earlier because there are weaknesses that actually cover that type of data.

    Ashley: Exactly.

    Britton: What are you doing with it.

    Ashley: Vulnerabilities in our software could lead to the loss of data. That could be a violation of those privacy laws of course, as well as other impacts, whatever it was. Well good. This has been a lot of fun. I’ve really enjoyed talking with you about this aspect of creating secure software. We’ve mentioned static code analysis and tools a little bit. I know this isn’t a commercial about Perforce, but would one of you just kind of position for us where in the process of what we talked about today where Perforce really plays in kind of your specialty in this area?

    Foster: Yeah, sure. So in terms of our product which our static analysis products, both Klocwork and Helix QAC, we fit in many different areas of kind of a development pipeline and process. We exist to make sure vulnerabilities are found while the developer is currently typing their code on their desktop. We also fit in for gated checks and quality checks in your SI/CD pipelines so we can quickly report back issues and also your typical if you’re running a nightly on a server or if you’re deploying checks and building your software in the cloud and provision instances and any sort of thing like that. We’re basically available anywhere. So we help you shift left as far as you want. We provide those security checks anywhere just for the ability to drive what I would call continuous compliance. 

    Ashley: Excellent. Great. Well, Stuart, Jill, it’s been a lot of fun talking with you and hope everyone – wish you the best in your journey on creating even more secure software. We’ll speak with you again soon. Take care. 

    Foster: Awesome. Thanks, Mitch. 

    Britton: Thanks.