devopsy.kinsta.cloud

Tag: devsecops

  • WhiteHat Security Allies With Bit Discovery on Vulnerability Intelligence

    WhiteHat Security Allies With Bit Discovery on Vulnerability Intelligence

    WhiteHat Security, a subsidiary of NTT, has announced an integration with Bit Discovery to make it easier for developers and cybersecurity teams to discover the extent to which the attack surface they need to defend might be impacted by a vulnerability.

    Bit Discovery maintains a database made up of more than 5 billion internet-connected assets and hundreds of third-party resources to automatically generate an inventory of the assets that make up an organization’s attack surface. Bit Discovery continuously scans internet-connected assets to monitor new domains, phishing sites and connected devices to provide cybersecurity teams with a deeper understanding of the threats their organization faces.

    WhiteHat Security integrated its application security platform for scanning for application vulnerabilities with the Bit Discovery database via application programming interfaces (APIs) to make it possible to search that database via a dashboard. All vulnerabilities surfaced via that dashboard are verified by WhiteHat’s Threat Research Center, a team of application security experts, to reduce any potential alerts that might actually be false positives.

    Craig Hinkley, WhiteHat Security CEO, said the goal is to make it simpler for organizations to shift more responsibility for applications security left toward developers in a way that doesn’t result in them chasing their tail every time a new vulnerability is discovered. Instead, a virtuous cycle of workflows can be created that enables developers and cybersecurity teams to collaborate more effectively, Hinkley added.

    Ultimately, the goal is to make scanning for application vulnerabilities a more natural extension of any quality assurance process. The simple fact that there is so much focus today on DevSecOps best practices only highlights how much work there is to be done before security becomes just another routine gate within an automated DevOps workflow, noted Hinkley.

    In the meantime, unfortunately, cybersecurity teams are finding it increasingly difficult to keep pace with the rate at which applications are being developed and updated. The Bit Discovery database integration provides a way for cybersecurity teams to have more relevant conversations with developers about which vulnerabilities need to be prioritized based on the actual threat they represent to the organization. In the absence of that integration, security becomes a losing battle, simply because developers and cybersecurity teams both are overwhelmed by the volume of vulnerabilities that would otherwise need to be investigated on their own without any assistance.

    The integration between WhiteHat Security and Bit Discovery comes at a time when the focus on software supply chains has increased significantly in the wake of a series of recent high-profile breaches. More attention is now being paid to preventing malware from finding its way into the application development process. The challenge is finding a way to provide developers with actionable insights into risks that need to be mitigated before and after an application is deployed in a production environment. After all, vulnerabilities are just as often discovered after an application is deployed as they are before.

    It may be a while before most organizations are able to implement a robust set of DevSecOps best practices, but the more reliable the vulnerability intelligence being provided to developers, the more likely it becomes they will act on it before a cybercriminal exploits it.

  • Empowering BizDevOps Teams With SLOs

    Empowering BizDevOps Teams With SLOs

    When BizDevOps teams are drowning in logs and false alerts and are spending more time on manual processes than on building and deploying new applications and features, the work suffers, morale suffers and the organization as a whole suffers. Releasing better and more secure software, faster and with real business impacts starts with a robust BizDevOps practice. A crucial step IT leaders can take to align the developer, operations and business teams is to create a shared language of service-level objectives (SLOs).

    SLOs are metrics for validating that software is meeting its technical and business objectives. Defining and implementing SLOs help align developer, operations and business teams, not only ensuring everyone is moving toward the same goals, but also providing a way to reliably measure how BizDevOps teams are progressing toward these goals.

    Here are three of the most impactful ways SLOs can empower your BizDevOps teams.

    1. Establish a Common Language Across the Delivery Cycle

    The best SLO gives you precise and actionable insight into your system. Take performance and resiliency engineering, for example. By defining SLOs for performance and error rates, teams can use common measurements to track progress toward meeting their quality criteria to ensure they are staying within their error budget.

    In this way, teams can use SLOs as a common language across the delivery cycle – something everyone from developers to operations to business teams can rally around, ensuring everyone is working toward the same outcomes. This aligns teams into a coordinated BizDevOps practice, where all sides have better insight into how each piece of the business feeds into the others. If an incident occurs, operations can use an AI-based observability platform to observe its trends and impacts across different product or service releases and automatically feed that information back to the developers, who can modify their builds accordingly. When everyone is using the same SLOs to speak the same language, BizDevOps teams can coordinate and communicate more easily and effectively.

    2. Creating a Culture of DevOps Resiliency by Shifting SLOs Left

    BizDevOps isn’t just a technical practice defined by tools and platforms. It’s also a culture change and a shift in mindset. SLOs can play a major part in this change. Shifting SLOs left into the delivery pipeline means giving developers feedback about the outcome of their work and real-time visibility into their business KPIs using consistent SLO measurements – ideally, on every code commit. This consistency gives them answers at their fingertips to make data-backed decisions that consistently deliver better business outcomes. Using SLOs for developer feedback is a fundamental building block of DevOps, but it’s also key to creating a culture and mindset of resiliency within BizDevOps.

    A resilient BizDevOps culture is more than just making changes to your technology stack; it’s about changing the mindsets of individual engineers and developers. Resiliency means strength and reliability; the trust that when something goes down, it’ll go right back up. It’s about building the processes and systems that guarantee flexibility for anything from managing crisis events to delivering service continuity. Shifting SLOs left helps facilitate this culture change by giving developers greater exposure to the impact their work has when it’s in production and when it’s deployed. It makes everyone feel they’re in the same boat, and recognizes developers, operations and the business teams as one cohesive unit.

    3. Integrating SLOs Into Remediation

    BizDevOps teams can use SLOs to enhance remediation and incident response efforts. With everyone working with the same metrics, BizDevOps knows with certainty when something is broken, can identify root causes more quickly and can develop agreed-upon incident responses to accelerate time to resolution. BizDevOps teams can then feed this incident response knowledge back into quality gates earlier in the development cycle to avoid future problems. This develops SLOs that have been “battle tested” and can be easily automated to make quality gate testing better on the development side, and incident response better and faster for the operations side.

    SLOs bridge the gaps between BizDevOps

    SLOs already serve a useful role in production, but they also can influence the ability to create a robust, resilient BizDevOps practice. Shifting SLOs closer to developers and using them as a shared language across the delivery cycle provides space for greater experimentation, more innovation and a culture of resiliency. SLOs can also be defined along business-relevant metrics, such as conversion rates, user experience or feature adoption. As a result, SLOs empower BizDevOps teams to respond more quickly to issues and deliver better digital experiences and business outcomes.

    SLOs aren’t just performance metrics – they’re a powerful tool for bridging the divides between the developer, operations, and business teams. SLOs can help cultivate a BizDevOps culture that delivers innovative, secure software faster and with tangible business value.

  • What Data Catalogs Don’t Reveal

    What Data Catalogs Don’t Reveal

    In today’s data intensive world, data catalogs, as the name implies, are simply catalogs of information (some human-entered and some extracted from metadata in systems). The importance of data in the enterprise has grown, and analytics plays an increasingly important role in generating value. So, while it’s important to collect and store and organize all this data, data catalogs are missing a major piece of the puzzle – they fail to draw accurate relationships between data assets and how they relate to (or are calculated from) each other.

    It is like having a catalog that contains a description of all the electronics components in the world, but without an understanding of how to assemble those components into a clock, a radio or even a computer. Or how to diagnose what needs replacing when the device stops working.

    Data catalogs cannot answer a whole host of questions along the lines of, “What are the consequences if I make a change to this dataset?” Even if the information in the data catalog is religiously updated, if a change was, in fact, made, users impacted by that change, whether directly and indirectly, have no way of knowing that a change was made. As a result, risk of unidentified issues is high.

    The table below summarizes the strengths and weaknesses of traditional data catalog products.

    Issue

    Data Catalog Strengths

    Data Catalog Weaknesses

    Data Discovery
    • Collect metadata information from a wide variety of systems
    • Give users flexibility to manually update information
    • Simplify searching for data assets across a wide variety of systems
    • Make it easy to identify the subject matter expert (SME) related to a dataset
    • Rely on manually maintained documentation
    • Do not automatically relate data sets to each other
    • Do not understand how data assets are calculated from each other
    • Fail to identify who uses a particular dataset (and how they use it)

    Data Governance
    • Provide a robust framework for managing the availability, usability, integrity and security of the data
    • Rely on manually maintained user-defined rules for dictating data access
    • Cannot automatically propagate access rules from one dataset to antecedent datasets

    Infosec Compliance
    • Make it easy for users to label personally identifiable information (PII) and other infosec risk data sets
    • Do not automatically infer the implications of data processing on the movement of PII inside the enterprise

    Data Quality
    • Data catalogs do not actually inspect data – so they do not assist with data quality issues
    • Complete failure to identify issues and communicate who those issues impact downstream from a data quality issue

     

    Data Discovery

    Data catalog solutions provide powerful frameworks for collecting metadata and facilitating documentation of datasets. The collection and aggregation of metadata is automated, and data engineers/analysts are, hopefully (but rarely), compliant in documenting their work so others can leverage it.

    Unfortunately, data catalogs fail to identify how datasets and processing rely on each other. There is no way to reliably identify which users access and rely on particular datasets, both directly and indirectly.

    Tasked with this objective, a data engineer can manually answer these questions by searching and analyzing the relevant data processing code. This approach uses expensive data engineering resources, takes time and results in reduced analyst and data engineering productivity.

    Data Governance

    When new data sets are created, the authors must tag the data to control data governance. Not only does this rely on compliance from the author, but the rules must be propagated to determine who can use the newly processed data. How should the rules be propagated? This is a complex issue. For example, the city in an address may be restricted, but aggregates across that city may not be. Defining these rules, in and of themselves, is complex — applying them is even more complex.

    Reliance on data engineers and analysts to comply with data governance documentation and systems for enforcement is error-prone and expensive. Sensitive datasets are at high risk of being exposed.

    Infosec Compliance

    Current solutions to information security compliance rely on:

    • Users manually documenting if their data processing activities use (or produce) infosec-sensitive data.
    • Automated identification of infosec-sensitive data by inspecting the actual data and using algorithms to identify how the data needs to be secured.

    Data catalogs are used to facilitate user documentation of data processing activities to comply with infosec compliance requirements. This process relies on humans manually maintaining documentation and systems (and performing actual data inspection.) These processes present significant security risks in and of themselves, because both data inspection – which itself presents a risk – and skilled manual work is required.

    Data Quality

    Data engineering already has processes to identify when there is an issue landing data in a table. Automated systems are available that inspect data values and make intelligent decisions (some even based on machine learning) about whether or not the data is acceptable. These systems exist outside of traditional data catalogs.

    The question is, who will that problem impact? You must identify who are the immediate users of the data. You must also identify the indirect users of the poor-quality data.

    The current approach to this problem is to have skilled data engineers review all data processing code and manually identify users to warn – this is both expensive and time consuming. Beyond this, the risk is that a user is not identified; what if the error impacts a report that lands on the CFO’s desk and they are not warned?

    Data catalog solutions are good at solving the problem for which they were initially designed – finding datasets that are of interest to data engineers and data analysts.

    The risk in DevOps is that data catalogs are relied upon for data discovery, data governance, infosec compliance and data quality issues that they fail to address in today’s complex data processing environments.

  • SecDevOps is the Solution to Cybersecurity

    SecDevOps is the Solution to Cybersecurity

    Anybody paying attention to world news will notice that the threats and risks perpetrated by cybercriminal actors, in many forms, is a serious problem on the rise, affecting individuals, organizations and nations daily. The cybersecurity threat space is indeed alarming and growing rapidly. The cybersecurity solution space is struggling to keep up. After all, there is no such thing as 100% security.

    What is the Solution to Cybersecurity’s Problem?

    In my opinion, the industry has long underestimated the problem of cybersecurity, which has resulted in solutions that do not sufficiently stand up to the cybersecurity threat space. What is clear is that solutions must come from rapid software changes that detect and plug security holes as fast as they are found, and continuously deploy innovative defensive solutions that keep bad actors off their guard. To do that requires Agile and DevOps continuous delivery practices coupled with a security-aware mindset.

    What is a Security Aware Mindset?

    To put things in perspective, it is useful to consider the mindsets of design, QA, operations and security.

    Design mindset – create a product or service that customers want, now. The Agile framework addresses this requirement.

    QA mindset – verify a product or service works the way customers expect it to, when it is released, for all production configurations available at the time of the release. The DevOps framework addresses this requirement.

    Ops mindset – ensure a product or service continues to work the way customers expect, for all production configurations, for the life of the product or service. The site reliability engineering (SRE) and ITIL frameworks address this requirement.

    Security mindset – defend valuables for organizations that create or use a product or service against unintended and malicious actions, by people and organizations, both inside and outside of the organizations, for all production and non-production configurations, for as long as there is something of value to protect. The DevSecOps framework was created to address this requirement; as we have seen, this does not yet offer sufficient safeguards for the growing cybersecurity threat problems.

    The security mindset has multiple additional vectors of thought required compared to the design, QA and ops mindset. This helps us to understand why the cybersecurity problem space is bigger and requires more comprehensive solutions.

    Not long ago I considered security assurance to be a subset of testing practices. In 2016, in my blog, “Seven Pillars of DevOps – Essential Foundations for Enterprise Success“, I did not break out security as a separate pillar. At that time, this type of thinking was typical of developers. Security was someone else’s job. Perimeter defenses were deemed sufficient.

    Soon after, I realized that way of thinking was naïve on my part. By the time that I co-authored a subsequent blog, “Nine Pillars of Continuous Security Best Practices,” I added a separate pillar for security specific practices, and also added security practices within each of the other pillars.

    In parallel, DevSecOps became a thing in the DevOps world. The idea of integrating security practices into DevOps makes a lot of sense, because DevOps is the answer to continuous delivery of software, and security needs continuous delivery of defensive solutions. However, simply adding security to DevOps is not a sufficient solution, because DevOps was conceived to address specific problems associated with design, QA and Ops – not security. Simply adding security as another metric for releases is not enough. What is needed is a re-think of how DevOps can be used to deliver continuous security, as indicated in my book, “Engineering DevOps.” This is the same idea behind what is referred to as SecDevOps.

    In my opinion, it is now time for SecDevOps to gain favor over DevSecOps when it comes to integrating security practices with DevOps practices. This represents a much more significant shift than simply putting security first in the name. With SecDevOps, security concerns within the entire development organization and at every stage in the DevOps value stream, are explicitly prioritized over other types of concerns. This makes sense, given the much wider blast radius of security events versus other quality concerns that DevOps was originally designed to address.

    With SecDevOps, security tools and resources are weighted at the highest priority level. SecDevOps and secure coding practices are required training for application developers. Threat modeling is part of the value stream. Security tasks that are required to mitigate security risks are given the highest priority in backlog planning. At each stage in the DevOps pipeline, security concerns rise to the top of the priority list. Release and deployment readiness are weighted at the highest level. In short, SecDevOps explicitly plugs some important security holes that are not covered by DevSecOps. With SecDevOps, security becomes continuous, not just an add-on to DevOps.

    What This Means

    By explicitly plugging some important security holes that are not covered by DevOps or DevSecOps practices alone, it makes sense for SecDevOps to now emerge as the preferred framework to close the gaps between the growing security problem space with the evolving security solution space. SecDevOps offers the required security-first mindset and solves the need for rapid software changes that detect and plug security holes as fast as they are found, and continuously deploys innovative defensive solutions to keep bad actors off their guard.

  • Why Businesses Need to Transform From DevOps to DevSecOps

    Why Businesses Need to Transform From DevOps to DevSecOps

    The need for modern applications to support continuous integration, delivery and deployment spawned the need for DevOps. Increasingly, as cyberthreats evolve and grow and application development methods and time frames change, security now needs to be an integral part of today’s application life cycle. As a result, businesses should move from DevOps to DevSecOps.

    DevSecOps is needed to address security implications introduced by changes in the way applications are now developed, deployed and updated. Some of the main drivers for moving to DevSecOps include:

    The speed and frequency of new apps creation and updates: It is no secret that developers are under great pressure to create new applications and features in faster time frames than ever before. Some industries such as banking and financial services are being challenged by nimbler FinTech organizations offering innovative services and better customer engagement. The same is true in retail versus online competitors. And most other businesses are in the midst of a digital transformation. All of this necessitates the development of more apps in shorter time frames.

    As the industry knows from DevOps, app development is just one part of the more extensive application lifecycle work that needs to be done. Here again, there is a change from tradition. Beyond the customary needs to update, patch and maintain applications, today’s users are accustomed to quick actions on their demands. They have an app store mentality. When they point out a flaw or suggest an enhancement, they expect these things to be addressed immediately.

    They want the same responsiveness in their business applications. It is no longer enough to put items in a Jira or some other project tracking solution for later consideration; actions must be taken immediately.

    In both the building and enhancing of the apps, the need for speed can overlook security issues.

    Cloud-native architectures: Many modern apps are built using cloud-native architectures based on loosely coupled microservices and containers. The architecture lets developers quickly build and update applications. The approach typically makes use of third-party and open source code to build a larger application. For instance, a loan processing application might include an open source decision engine, an outside financial institution’s credit rating service and a commonly used mobile app user interface.

    Another advantage of using a cloud-native architecture is that changes can be made quickly. Rather than writing a monolithic app from scratch or recoding an entire app when small changes need to be made, changes only need to be made to impacted elements. If a new feature needs to be added to a front-end mobile user interface, that’s the only element of the app that must be changed.

    These conveniences that make cloud-native so well-liked in the development community, again, can mean that security issues are overlooked.

    Low-code/no-code and composable applications: New technology such as low-code and no-code platforms abstract details about the code from developers. And they enable citizen developers, who certainly do not have an eye for security, to build their own apps. Composable techniques further simplify application development via the reuse of components.

    Bringing Security Into DevOps

    The implication of these industry changes is that security needs to be entrenched in the process throughout an application’s life cycle. It is no longer enough to test for vulnerabilities after the fact.

    Specifically, security operations must be integrated at every step of application development, modification, and deployment. It must be real-time instead of reactive. Security can no longer wait for a breach or attack; it must constantly examine the elements of an application as they operate and are modified.

    Additionally, DevSecOps is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s cobbled-together applications. The bottom line is that implementing cybercrime protection at the code-level and secure coding practices are lower cost, more efficient and more effective than trying to patch security holes in a finished application.

  • Trend Micro Allies With Snyk to Advance DevSecOps

    Trend Micro Allies With Snyk to Advance DevSecOps

    Trend Micro and Snyk unveiled today a software-as-a-service (SaaS) platform the two companies have jointly developed to identify vulnerabilities in open source code.

    The Trend Micro Cloud One – Open Source Security by Snyk platform enables DevOps teams to both identify vulnerabilities and licensing issues to better monitor, prioritize and share information about risk and exposure rates within application development projects.

    Trend Micro COO Kevin Simzer said the SaaS platform provides a unified approach that combines six services within a single subscription to enable organizations to better protect a software supply chain.

    Snyk CTO Geva Solomonovich said that while the relationship between the two companies is not exclusive an alliance with Trend Micro will enable organizations to employ Snyk tools and the open source vulnerability database to implement a set of best DevSecOps practices within their organization.

    Simzer said Trend Micro is also including automation tools that make it easier for cybersecurity teams, along with the rest of the IT organization, to discover what application development projects are underway with their organization. The goal is to provide cybersecurity teams and DevOps teams with a set of tools that provides them with a common language through which they can collaboratively address vulnerabilities.

    Trend Micro claims approximately eight hours can be saved per vulnerability through automation and early discovery of the versions of open source code being employed. Roughly 80% of all application code in use today is derived from open source software, noted Trend Micro. That translates to saving more than 650 hours of development time per application, according to the company.

    Snyk, meanwhile, claimed to have observed a 2.5x increase in the number of open source vulnerabilities it has discovered over the past three years. In the wake of some recent high-profile breaches the security of software supply chains has become a greater area of focus, with many organizations now implementing a more rigorous review of all the code they employ and any associated dependencies.

    It’s still early days as far as adoption of DevSecOps best practices are concerned within most organizations. Responsibility for application security is clearly shifting further left toward developers. As part of that effort, cybersecurity teams are trying to adjust their processes in a way that enables them to vet the efforts of developers without slowing down the rate at which applications are developed. That’s becoming more challenging as the rate at which applications are being developed continues to increase.

    The conundrum organizations are trying to navigate is that every minute a developer spends on security is, theoretically, one less minute they have to write applications or business logic. At the same time, however, if vulnerabilities are not addressed early in the development cycle, they may take longer and cost more to fix, especially if they are discovered after an application is deployed in a production environment.

    Of course, there may come a day a when application security is just another set of steps to be performed within a quality assurance process. In the meantime, however, a lot more attention is being paid to application security today, in part, to make up for the many sins of the past.

  • The Basics of DevSecOps Adoption

    The Basics of DevSecOps Adoption

    Embracing DevOps is essential, but keeping the software delivery and deployment pipeline safe has become more critical than ever. While attackers are keen on getting into your Docker containers or Kubernetes clusters, securing your images, pods and clusters can deter attackers. Securing your artifacts, deployment workloads and production environments remains critical today. While we have many tools to get these jobs done, it is vital to understand DevSecOps and its related factors.

    DevSecOps has become a mass movement today. But what makes it so important?

    What is DevSecOps?

    DevSecOps addresses software development security via the mindset that everyone is responsible for security at every stage in the development process.

    DevSecOps is a culture and an evolution where security is given the utmost priority in the software development life cycle (SDLC). Security is everyone’s responsibility, and inspection is done at each stage of the development cycle. Basically, implementing a process for inspecting, scanning and reviewing code by developers at predetermined checkpoints to immediately tackle any identified bugs or vulnerabilities. One of the most challenging parts of the transition from DevOps to DevSecOps lies in building more open and communicative teams.

    Why DevSecOps?

    Using DevSecOps, security becomes an integral part of the planning, coding, building, testing, deployment and production stages. DevSecOps makes continuous testing the default for developers and security professionals to deliver more secure features to the market more quickly.

    In many organizations, most development, operations or DevOps teams see security or security teams as a roadblock to getting things done faster; delaying features. In traditional DevOps implementations, the security aspect was missing, DevSecOps was introduced to stress the priority of security in DevOps.

    The Importance of DevSecOps

    Let’s take Uber’s security breach in 2017 as an example. Personal details and information of 57 million customers and over 600,000 drivers was exposed. Uber paid a $100,000 ransom to hackers in an attempt to get them to delete the breached data. This breach happened because engineers failed to secure and update the credentials they were using on GitHub.

    Similarly, in 2018, Tesla’s Cloud was hijacked and used to mine cryptocurrency by abusing a vulnerability in the company’s Kubernetes cluster. A significant amount of FedEx data was also exposed in the same way, affecting 119,000 individuals.

    Logz.io’s annual DevOps Pulse 2020 survey revealed that, out of 1,000 respondents, only 3% indicated their development methodology as DevSecOps, hinting at the slow pace of DevSecOps adoption in the industry.

     

    Image source: Logz.io

    DevSecOps Best Practices

    Adopt a Shift Left Approach

    Shifting security left helps organizations secure each stage of the development life cycle. This refers to starting testing earlier in the SDLC. The goal here is to enhance quality, cut down long test cycles and reduce the likelihood of unpleasant security surprises at the end of the development cycle or in production.

    Include a Threat Modeling Mechanism

    It is essential to implement a threat modeling mechanism in DevOps workflows since it helps developers and security professionals to view software from an attacker’s perspective. It makes developers more careful while writing code and encourages them to more closely follow code writing and review best practices. Threat assessment or threat modeling will also help identify potential vulnerabilities in system design and architecture, and acts as a crucial part of successful security integration in the SDLC.

    Mandate Developer Training

    Training developers on the importance of security is a critical best practice. Making sure each developer who writes, tests and deploys code understands that security is part of their job description is a priority. Training developers on security best practices, how to embed security, check for vulnerabilities and use appropriate security tools will improve overall security knowledge and increase its application within the organization. 

    Use Available Security Vulnerability Tools

    A vulnerability is considered a flaw in the code, application dependencies, external libraries, licenses used or operating system (OS) packages. There are a number of static and dynamic application security tools that can help the development team to find and address bugs and vulnerabilities as early as possible in the development pipeline. Many are automated to reduce the time it takes for developers to find these flaws.

    Sponsor Bug Bounties

    Bug bounty programs and rewards motivate external and internal security experts to experiment with the platform, analyze, think outside the box and report any major bugs and security flaws found. 

    Security-as-Code

    Security-as-code is the next evolution in DevOps, where security is fully embedded in the development processes. This practice implements security and secure coding practices in the earliest stage of development. With security-as-code, developers will be able to identify vulnerable code ahead of time and add security checkpoints/measures to tackle such irregularities. 

    DevSecOps Tools

    When we talk about DevSecOps, the software development cycle involves multiple checkpoints to identify bugs and any other vulnerabilities and resolve them so that the application works as designed. The aim is to deploy software with quality and confidence, and this is achieved by using various tools at different stages.

     

    Image credits: CatchPoint

    Organizations can choose to use the type of security tools that best work for their needs from their preferred vendor. While the security tools themselves are critical for detecting vulnerabilities in the application through the DevSecOps pipeline, monitoring is also considered an integral part of this process. It not only lets developers analyze and evaluate security vulnerabilities from the end user’s viewpoint, but it can help identify breaches and anomalies after an application is in production.

    DevSecOps Pipeline

    While DevOps focuses on speed and agility, DevSecOps adds a layer of security throughout the software development life cycle. A DevSecOps pipeline adds security activities to every stage of the development process, not simply tacking it on to the end as an afterthought. This is achieved by integrating security checkpoints, controls, policies, tools and techniques from the beginning of the DevOps pipeline until the end. These additions facilitate automated security controls at each stage of the software delivery pipeline.

    Image credits: JFrog

    In his swampUP conference keynote The Divine and Felonious Nature of Cyber Security, John Willis shared some valuable DevSecOps best practices, including:

    • Treat security issues as you would software issues.
    • Adopt a “security-as-code” approach to enable the automation of security.
    • Build security controls and vulnerability detection into CI/CD pipelines.
    • Automate security testing as part of the build process.
    • Proactively monitor the security of production deployments.

    Embedding security earlier in your software development life cycle will yield bug-free features and satisfied customers. Have security checkpoints at each stage and make sure developers understand that security is everyone’s responsibility, including theirs. Manage your software and build artifacts, scanning and securing them at every stage of the pipeline using appropriate tools and techniques. Happy DevSecOpsing!

  • DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More

    DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More

    We are excited to announce the return of DevOps Connect: DevSecOps Virtual Summit on May 19, as part of the RSA Conference 2021. This year, internationally recognized speakers will take a deep dive into “Securing the Cloud Native World.”

    DevOps Connect is a full-day event, featuring four different content tracks, with more than 50 speakers, including keynote presentations, demos, insight talks and featured sessions.

    The agenda features a mix of topics, including cloud security, CI/CD, Kubernetes, GitOps, AppSec, security risks, shift left, open source, case studies covering DevSecOps and more. Attendees will learn how the finance, manufacturing, healthcare and hospitality industries are securing their cloud environments, and how to better secure and monitor their systems.

    DevOps Connect 2021 Lineup

    DevOps Connect 2021 features an exceptional lineup of the most prominent and respected security and DevOps leaders, including:

    • Featured keynote speaker: Christopher Krebs, former director of the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), and co-founder of Krebs Stamos Group LLC
    • Chenxi Wang, founder and general partner at Rain Capital
    • Allan Friedman, director of cybersecurity initiatives at National Telecommunications and Information Administration in the U.S. Department of Commerce
    • John Willis, senior director of Global Transformation Office at Red Hat
    • Cyndi Gula, managing partner at Gula Tech Adventures
    • Alessandro Vozza, principal software engineer at Microsoft
    • Caroline Wong, CSO at Cobalt
    • Thomas Krane, principal at Insight Partners
    • Charles J. Kolodgy, principal at Security Mindsets LLC and analyst at Accelerated Strategies Group
    • Nisha Kumar, open source engineer at VMware
    • Mike Rothman, president at DisruptOps
    • Dave Howell, VP at ZeroNorth
    • Maciej Mensfeld, senior product manager at WhiteSource
    • Matt Wilson, senior product manager at GitLab
    • Erkang Zheng, founder and CEO at JupiterOne
    • Philippe Humeau, CEO at CrowdSec
    • Jennifer Czaplewski, director of product security at Target
    • Al Sargent, senior director of product at InfluxData

    Former CISA director Christopher Krebs, our featured keynote speaker, will be answering questions from the audience during a live Q&A.

    Workshop Friday

    We are also hosting Workshop Friday, as we wrap up the RSAC 2021, offering live workshops designed to be as interactive and hands-on as possible with experts from Google, JupiterOne, Sysdig and Sonatype. These workshops provide professional guidance and training on a variety of topics, including Site Reliability Engineering (SRE), AWS cloud security and protecting against supply chain attacks. On May 21, attendees will have the opportunity to interact with the experts, share their process, get immediate feedback and personal assistance. Each workshop will be live-streamed through our online platform at no cost to attendees. We have limited spots available. Seats are reserved on a first-come, first-served basis. To save your spot, visit the Workshop Friday website.

    A Unique Virtual Environment and a Few Surprises

    The virtual environment features an auditorium with different tracks where attendees can watch the sessions by industry experts. There will be an expo hall lined with booths featuring interactive chats and downloadable resources. The expo hall will be open throughout the event, giving attendees the opportunity to chat with sponsors, including GitLab, Prisma Cloud by Palo Alto Networks, Sonatype, WhiteSource, Sysdig, JupiterOne, Snyk and more.

    We have a few surprises planned to make this year’s DevOps Connect extra special. Take a break between presentations, grab your yoga mat and enjoy a Pilates class by a certified instructor, dance to the music of our featured DJ and check out how to make a delicious cloud drink by a professional mixologist. You can also participate in a raffle to win a copy of “You Can Stop Stupid” by Ira Winkler, author and president at Secure Mentem, and a copy of “Security Yearbook 2020” by Richard Stiennon, industry analyst at IT-Harvest.

    DevOps Connect 2021 offers the best of a physical environment in a virtual context combined with the advantages and convenience that a virtual environment offers.

    Registered attendees will receive a link to access the virtual environment on-demand. To check out the full agenda and to register, visit the DevOps Connect website.

  • The Time for Collaborative Security Is Now

    The Time for Collaborative Security Is Now

    As Bruce Schneier famously said, “security is a process, not a product.” We commonly see companies pour millions of dollars into cybersecurity products and tools to protect against vulnerabilities and lower risks, and yet, more often than not these ample funds are not enough to defend against attacks. 

    Within the span of two decades, we have seen how social power can be leveraged to benefit the masses with applications like Waze, Airbnb, Uber and many others. This same innovative idea could revolutionize the way the cyber world operates by giving security professionals the edge in identifying potential threats. 

    CrowdSec CEO Philippe Humeau recognizes the capabilities of crowd power to invigorate the cyber realm. The community firewall created by CrowdSec uncovers thousands of malicious IP addresses worldwide and helps cripple hacker behavior before it can evolve into major cyberattacks and data breaches. Additionally, the start up just announced it raised $5 million to help take the collaborative firewall to the next level as they work to transform the cybersecurity landscape. 

    In the interview below, Philippe emphasizes the benefits of collaborative, open and transparent security environments in tipping the scales against the hacking dilemma that plagues companies across the globe. 

    Join Philippe at DevOps Connect 2021 on May 19, during the RSA Conference, where he expands on this topic in his session “The Age of Collaborative Security.” Also, learn more about CrowdSec and see a demo of the tool during his spotlight session, “Introducing CrowdSec, The Open-Source Massively Multiplayer Firewall.”

    To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.

  • How to Bring DevOps and Security Teams Closer Together

    How to Bring DevOps and Security Teams Closer Together

    More often than not, there seems to be friction between DevOps and security teams. Despite having the same end goals of creating the most secure code and preventing any potential security pitfalls, these groups of professionals often lack the unity needed to accomplish these end goals effectively and efficiently. 

    In the interview below, Naomi Buckwalter, director of information security and IT at Beam Technologies, addresses this issue and outlines key ways development and security teams can come together to better accomplish their shared missions. She stresses the importance of security professionals reaching out a hand to their DevOps counterparts to teach them how to be security-forward when writing code. However, she highlights how not every security expert has a developer background, so it really takes these two groups of skilled tech specialists working in unison to fill those knowledge gaps for each other.

    Naomi brings over 20 years of IT and security experience to her upcoming session “Six Things Developers Want From InfoSec,” at DevOps Connect 2021, during the RSA Conference. She will expand on some of the key topics discussed in this interview during her talk on May 19 at 4 p.m. EDT.

    To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.