staging-devopsy.kinsta.cloud

Tag: devsecops

  • Why Developer-First is the Future of AppSec

    Why Developer-First is the Future of AppSec

    DevOps culture and rapid cloud adoption mean developers are shipping code faster than ever and, in many cases, security teams struggle to keep up. To avoid relegating security to afterthought status, organizations must shift left and adopt a developer-first approach to application security (AppSec).

    Organizations that depend on software development need a solution that accomplishes two essential things to adapt and survive: Risk-appropriate security measures and an even distribution of functions across the stack. First, risk-appropriate security measures must be applied to all software before it is delivered or deployed. Second, they must adopt processes that enable security functions to be distributed across the development stack in a way that will not slow down the pace of development.

    Just as the entire development process starts with developers, integrating security should also start with a developer-first approach. Developer-first AppSec is the future; here’s how organizations can evaluate tools that will help them adopt a developer-first approach.

    Why Developer-First is the Future

    Developers outnumber application security engineers by as many as 100 to one, and AppSec functions cannot scale if security practitioners are the only ones responsible for security. This imbalance suggests that organizational leaders must better distribute security ownership across the developer teams that own the software asset.

    As it stands today, many companies expect developers to build and deploy software faster than ever before. Security teams often can not keep pace with software development, and they become a roadblock to software delivery. To meet project development deadlines and their key performance indicators (KPIs), developers tend to leave security teams behind. They do not have the time or the incentive to slow down development because application security tools or processes are slow and cannot keep up.

    Security and developers are at cross-purposes in today’s software development model. They are pseudo-adversaries because AppSec teams know what it takes to make code secure, or at least they know how to find vulnerabilities. And, on the other hand, developers need to write code that works well and meets the sprint’s deadline.

    Friction Between Teams

    This growing problem creates friction between these two teams. It’s not that security teams don’t care about the organization’s need to produce quality software quickly or that developers don’t care about security. It’s just that each team is measured and incentivized to achieve opposing objectives. AppSec programs must create a developer-first approach to building software quickly and securely to combat this growing problem.

    It is not feasible for organizational leaders to provide security engineers with the entire business or environmental context behind software applications. In this sense, AppSec teams are working with limited vision. They may not see how the software fits into the organization’s big picture or understand its priorities.

    With limited contextual understanding, security teams necessarily rely on developers to make decisions about acceptable risks. If left to their own devices to view the world through a security-centric lens, AppSec teams could get bogged down—potentially spending too much time enforcing security measures that do not apply to the task at hand.

    Since developers are building the software and know what the services are designed to do, security engineers must defer to a developer-first approach so that decisions about security issues will align with the business context and acceptable levels of risk.

    Finding a Developer-First AppSec Platform

    Below is a condensed guide to help organization leaders evaluate potential AppSec platforms. These questions will help identify a solution that will enable the organization to build a developer-first security program.

    • Will the solution flood the developers and AppSec team with more and more results, or will this help them fix the essential gaps?
    • Will the solution provide context to help developers focus their limited time on security work that matters, or will it end up wasting time on things that may not even present a risk?
    • Will the solution help build security measures as guardrails to prevent security issues in the first place?
    • Is the solution flexible enough to enable building custom application security checks and policies in the SDLC?
    • Does the solution provide flexible ways of communicating actionable security information directly to developers in real-time within dev tools like source control systems, CI/CD platforms or engineering task management systems?

    There are an overwhelming number of application security solutions on the market today, most of which are designed to create security alerts about every conceivable threat regardless of the business context of the software being developed. More tools are then needed to manage the identified vulnerabilities.

    What This Future Will Look Like

    AppSec teams must recast themselves as security facilitators providing expertise for solving complex challenges and maintaining oversight of the developer teams’ security efforts. Developers should own tactical security tasks, but the AppSec team should continue to be the experts in making risk-based decisions and driving security accountability across the business.

    Inside many organizations, application security is only beginning to become integrated into developer workflows. This integration creates both opportunities and challenges. As organizations strive to make AppSec an enabler that aids developers in creating secure software quickly, developer-first AppSec programs let businesses make their digital transformation journey safer and faster.

  • WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

    WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

    WhiteSource has added the Microsoft Azure DevOps platform to the list of continuous integration/continuous delivery (CI/CD) platforms its open source vulnerability scanning tools natively supports.

    Susan St. Clair, director of product management for WhiteSource, said while developers are always encouraged to scan for vulnerabilities, it’s more effective if organizations implement scanning by default every time there is a merge request. That approach reduces friction because organizations become much less dependent on developers to scan for vulnerabilities within the context of a larger DevSecOps workflow, she added.

    WhiteSource also provides a merge confidence feature that uses crowdsourced data to show how likely it is that an open source component can be updated without breaking the build. Merge confidence includes data on upgrade age, adoption and compatibility to create a confidence score.

    The WhiteSource integrations make it possible for DevOps teams to detect all open source components being used and automatically enforce security policies directly from their repository. DevOps teams are provided with vulnerability and misconfiguration alerts and license violations along with detailed remediation guidance, including suggested fixes and prioritization advice, within an existing workflow versus being required to switch to a tool that has a separate user interface (UI) they need to learn.

    Should a merge request introduce a new error, the developer is given immediate feedback to resolve any newly introduced vulnerabilities before the request is completed. That approach to separating feature branches and mainline branches prevents interruptions to workflows. The enterprise edition of the WhiteSource tool also automatically generates pull requests in the repository to update vulnerable open source components to the lowest non-vulnerable version.

    WhiteSource also supports code repositories such as GitHub, GitHub Packages, JFrog, Bitbucket and GitLab. The Azure DevOps platform is gaining traction as more application development projects are being managed via the cloud following the onset of the COVID-19 pandemic, noted St. Clair.

    As more organizations begin to embrace DevSecOps workflows each of them will need to decide how far left they want to shift responsibility for application security. In theory, each developer is now being held more accountable for every one of their applications that gets deployed in a production environment. In practice, most developers lack the expertise required to ensure applications are secure.

    There are, of course, more concerns being raised about the security of software supply chains that include open source software in the wake of the recent disclosure of zero-day vulnerabilities in the widely-used Log4j logging tool. Many of the maintainers of smaller open source projects lack the resources required to ensure there are no inadvertent vulnerabilities that could be exploited by cybercriminals. More challenging still, many developers may have used an older version of that software that has known vulnerabilities.

    It’s not clear how open source software will ultimately be made more secure. In the meantime, however, it’s clear the onus for ensuring the security of that software is on the DevOps teams that employ it.

  • Taking a DevSecOps Approach to API Security

    Taking a DevSecOps Approach to API Security

    An application programming interface (API) is a data transfer approach that enables services within an application to talk to other applications (or other services within a system). Essentially, it enables Service A to talk to Service B in a uniform way. Companies benefit from APIs on a daily basis without even thinking about them. APIs are a way for companies to gain market share from competitors and monetize applications in new and exciting ways. For example, every time someone signs on to their favorite social media platform or shops on Amazon, the application is utilizing APIs to fetch and update the data with which they are interacting.

    Discovering and securing APIs is a never-ending battle for IT teams across all industries. APIs, for all their benefits, open new attack surfaces targeting a company’s data via vulnerabilities and exposures. In Gartner’s recent report, API Security: What You Need to Do to Protect Your APIs, the analysts estimated that for 2021, 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the user interface (UI), up from 40% in 2019. This turned out to be accurate.

    Traditional Approaches to API Security

    Traditionally, APIs are protected by enterprise API gateways and content delivery networks (CDNs). Although these approaches hedge against most brute force and denial-of-service (DoS) attacks, a more nuanced and sophisticated attack can breach these protections. The traditional approaches to API security are littered with limitations.

    Companies typically use two types of APIs – customer-app-facing APIs also called “north-south APIs” and internal APIs called “east-west APIs.” The external type is exposed to all public internet traffic. External developers can make requests and receive responses to these customer-facing APIs and take advantage of the functionality and data of an application while bypassing the user interface (UI). Internal APIs, however, are exposed only to intra-application traffic. For example, the cart service may call the user service via an internal API during the checkout process of an e-commerce application.

    Customer-facing APIs tend to be a bit more stable, visible, and targeted at a developer audience. The largest challenge of these north-south APIs is ensuring that this layer is secure every second of every day. This open and accessible API is designed to be utilized by developers outside the publisher’s organization. The goal is to leverage a community of technical audiences and increase usage of the organization’s data and services. Occasionally API publishers encourage developers to create applications that expand on the core business.

    While internal developers may call north-south APIs for their application development, the more common east-west API calls between services often drive much of the incremental feature development and new innovations. These APIs may or may not be accessible by developers outside the publishing organization. However, increasing numbers of east-west APIs are native in the public cloud so the attack surface can easily be exposed publicly. Further, changes to these east-west APIs are made constantly — as fast as a company’s DevOps and CI/CD practices allow. Unfortunately, this speed of change makes mistakes, errors, and security oversights more likely. These APIs and changes are less visible, which leaves companies at risk of discovering vulnerabilities only after a hacker has breached private data.

    Security Breaches of APIs

    Data leaks through all APIs, but companies can’t protect what they don’t know. The moment APIs are exposed on the internet, they create attack vectors for hackers to extract data. If some of the largest companies in the world have insecurities throughout their codebase of APIs and services, we can bet every other company does too.

    Security breaches of APIs are so dominant because APIs are such a ubiquitous method of passing information. Data breaches come in many forms, but they almost always affect company revenue and reputation. New API breaches and vulnerabilities are discovered almost daily. Capital One, Microsoft, T-Mobile, Symantec, McDonald’s, Instagram, Salesforce.com, and Venmo have all experienced major API breaches in the past few years.

    The DevSecOps team or security specialists should make ongoing risk-based decisions on when certain issues should be mitigated, and where in the CI/CD pipeline those concerns should be tested. However, in key scenarios, active protection is required to prevent a security incident from occurring or escalating. IT teams need to use tools that add this layer of protection without requiring humans to be involved.

    The traditional approaches to API security, although helpful at reducing the attack surface, are too slow to keep up with the ever-evolving tactics of bad actors. Only with a clear and full-stack view of an application’s security can IT manage risk and enforce appropriate security policies. Without better telemetry and observability, every security decision will be a shot in the dark and critical holes in API security will be missed.

    Consistently and Constantly Analyze

    Security processes and tooling should constantly analyze the cloud environments, API gateways, logs, web and mobile applications, as well as source code for changes that might create vulnerabilities. Once IT is able to identify the changes to their system, they can confirm that authentication, authorization, encryption, access and verification meet the standards set for the team.

    Active protection without human intervention is the only way to achieve real-time enforcement of security policies and protect against attacks as they occur. Ideally, a security solution should automatically discover and inspect for API security vulnerabilities, while humans analyze the situational risk and prioritize the work.

    With active protection in place, when a security incident occurs, IT will be able to rapidly leverage critical information to appropriately identify the components of the system affected and the contributing factors that led to the event, and protect the data.

  • App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

    App Store Antitrust Bill | GDPR vs. Google Fonts | Wordle Worth $1M+

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The Open App Markets Act polls well among devs, Germany fines a website for using Google Fonts, and the New York Times buys Wordle for an unfeasible sum.

    1. Antitrust Bill Would Open Up App Stores

    First up this week: The Open App Markets Act seems like a big hit with developers. In a survey, more then 80% wanted lawmakers to pass this bipartisan Senate bill.

    Analysis: But 30% of nothing is nothing

    One of devs’ biggest complaints is Apple’s 30% cut of all revenue—including in-app purchases. Many devs have also experienced random rejections of submissions to the stores. And these seem to be the main driving forces behind devs’ calls to tear down any walls around the gardens. But they should be careful what they wish for—users might not see it the same way.

    Karl Evers-Hillstrom: 8 in 10 app developers back measure to rein in Google, Apple

    The Coalition for App Fairness, [an] industry group for app developers, is pushing Congress to pass the Open App Markets Act. [The] bipartisan Senate bill … would block app stores from favoring their own in-house apps in searches, requiring developers to use their payment systems and preventing users from downloading apps from third-party stores.
    …
    Developers surveyed … complained about exorbitant fees … and expressed how they’d experienced difficulty getting their apps featured or accepted by app stores. Just 13 percent of app developers surveyed oppose the bill. … The margin of error is plus or minus 7.11 percentage points.
    …
    The proposal, co-sponsored by Sens. Amy Klobuchar (D-Minn.), Richard Blumenthal (D-Conn.) and Marsha Blackburn (R-Tenn.), is scheduled for a committee markup this week. The CEOs of Apple and Google have personally lobbied lawmakers to abandon [such] antitrust legislation.


    Wouldn’t that just kill the proverbial golden goose? No, says this Anonymous Coward:

    The only reason Apple has any success with the iPhone is because developers write apps for it, it’s no different to Windows in that regard. … If Apple’s app store is so good then everybody from developers to end users will continue to use it and nobody will use third party app stores.
    …
    Obviously there is a clear profit motive to exclude any competition in the app store space. But I don’t understand how people can claim that Apple makes great products and simultaneously argue that they couldn’t possibly survive competition on the platform.


    But Dr. Edith Müdyk—@BabyHueby—doesn’t sound hopeful this will go anywhere:

    Too bad policy isn’t dictated by public opinion.

    2. German Court Fines Site for Using Google Fonts Without Consent

    Did you know you need to get permission from a European user before you remote-load a Google Font? You do now.

    Analysis: Schrems II comes home to roost

    More GDPR popups ahoy! A German court has “clarified” that websites and apps should obtain informed consent before loading content—if loading it would reveal a user’s IP address to a third party. Luckily, the fine was only $110—this time, but if the perp was to do it again, the court threatened 2500× that amount.

    Thomas Claburn: Website fined by German court for leaking visitor’s IP address via Google Fonts

    A German court fined an unidentified website €100 ($110) … for violating EU privacy law by importing a Google-hosted web font. [It] passed the unidentified plaintiff’s IP address to Google without authorization and without a legitimate reason for doing so. And that violates … GDPR.
    …
    The website could have avoided this drama by self-hosting the font. … The ruling explicitly cites this possibility to assert that relying on Google-hosted Google Fonts is not defensible under the law.
    …
    The ruling directs the website to stop providing IP addresses to Google and threatens … a fine of €250,000 for each violation, or up to six months in prison, for continued improper use of Google Fonts. … These data privacy judgments … reflect the consequences of the EU Court of Justice’s 2020 decision to strike down the Privacy Shield data protection arrangements that had previously allowed US companies to exchange data with European partners under “Standard Contract Clauses.”


    Isn’t that ridiculous? And surely not the intention of GDPR? Aristos Mazer very much disagrees:

    This is very much the intended consequence, with a lot of analysis going into this regulation. … Even if that means redesigning foundations of the network.
    …
    Forcing sites to stop transferring data in any way shape or form to Google, Apple, Microsoft, Facebook, etc. … is exactly the goal. [It’s been] repeatedly validated by polls of EU citizens.


    And indeed, the point is to get “informed consent.” Here’s Hans Neeson-Bumpsadese:

    “To proceed beyond this point … your IP address needs to be shared with a 3rd party.” Would they click on that? … I know at least one person who would read that as, “If I click that link then you will tell people where I live.” (I know because they got a pop-up like that once, and phoned me in a state of mild agitation.)

    3. Wordle Sold to NYT for Over $1M

    Josh Wardle, a Welsh developer living in New York, has sold this winter’s social gaming hit to his state’s namesake newspaper of record. The New York Times thinks it’ll be a useful addition to its Games section. But the price tag is incredible.

    Analysis: Nice payday for Josh

    How much? Hard to see how the Times is going to make money out of this. Tomorrow’s word must be: NOROI.

    Alexis Benveniste: The Sudden Rise of Wordle

    In less than six months, Wordle has gone from a gift to a viral sensation, to … part of The New York Times. … Josh Wardle, a software engineer in Brooklyn, created the game as a gift for his partner … and it exploded in popularity.
    …
    Nearly two months later, 300,000 people played it. … The buzz around the game can be attributed to the spoiler-free scoring grid that allows players to share their Wordle wins across social media.
    …
    Wordle was acquired for an undisclosed price in the low seven figures.


    In other words, north of $1 million. Not bad for a quick, one-dev hack by Josh Wardle:

    The game has gotten bigger than I ever imagined (which I suppose isn’t that much of a feat, given I made the game for an audience of one). … I feel so grateful for the personal stories some of you have shared with me.
    …
    [But] I’d be lying if I said this hasn’t been a little overwhelming. [So] I am incredibly pleased to announce that I’ve reached an agreement with The New York Times. … I’m thrilled they will be stewards of the game.


    But “RIP Wordle,” mourns _xeno_, seemingly speaking for many:

    It’s about to be bogged down with trackers, and then later, ads. … A paywall is almost certainly on its way—The New York Times very carefully said it would “initially remain free.” … Not surprisingly, there are already plenty of clones. … There’s no way for the New York Times to make money off this.

    The Moral of the Story: No disguise will hide one’s true character.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Masahiro Miyagi (via Unsplash; leveled and cropped)

  • Linux Foundation Survey Sees Rise in SBOM Use

    Linux Foundation Survey Sees Rise in SBOM Use

    A global survey of 412 organizations published today by the Linux Foundation found nearly half of respondents (47%) producing or consuming software bills of material (SBOMs), and more than three-quarters said they expected to produce or consume them in 2022.

    SBOMs have become a bigger area of focus in the wake of a series of high-profile software supply chain-related breaches. The breaches involved application components compromised by malware that had been surreptitiously inserted during the application development life cycle. The Biden administration has gone so far as to issue an executive order requiring all agencies to provide SBOMs for all the commercial and custom software they use, but as of yet a deadline for compliance with that order hasn’t been set.

    In general, the Linux Foundation survey found that a large percentage of respondents (82%) are already familiar with the term SBOM. Respondents cited various benefits of having an SBOM, including making it easier for developers to understand dependencies across components in an application (51%), making it easier to monitor components for vulnerabilities (49%) and making it easier to manage license compliance (44%).

    However, the survey also makes it clear there is much SBOM work to be done. A full 62% of respondents, for example, are looking for better industry consensus on how to integrate the production/consumption of SBOMs into their DevOps practices. Respondents also cited a need for consensus on the integration of SBOMs into their risk and compliance processes (58%).

    More than half (53%) also said there is a need for better industry consensus concerning how SBOMs will evolve and improve.

    The survey also makes it apparent that organizations are more aware of the role SBOMs play in securing supply chains. A full 80% of organizations are aware of the White House’s executive order on improving cybersecurity, with more than three quarters (76%) considering making changes as a direct consequence of the order. Overall, the survey found the top consideration organizations focus on when evaluating open source software is security.

    Stephen Hendrick, vice president of research at the Linux Foundation, said 2022 is likely to be remembered as the year of the SBOM. There are several standards for building SBOMs, including an open source software package data exchange (SPDX) specification backed by The Linux Foundation and the Joint Development Foundation that is now recognized as the ISO/IEC 5962:2021 international standard. There is also CycloneDX, a lightweight SBOM standard based on an open source project that originated via the Open Web Application Security Project (OWASP) community and a software identification (SWID) standard for tags that some organizations use to create SBOMs.

    SBOMs are, essentially, a tool for listing the components that make up an application and are used inconsistently. However, when a critical vulnerability is discovered, they can sharply reduce the amount of time required to discover all the software components that need to be remediated. The challenge is, with the rise of containers, it has become much simpler to rip and replace software components in a way that may not always be reflected in the SBOM. Hendrick said in time, advances in technologies such as machine learning algorithms should make it easier to instantly reflect those changes in an SBOM.

    Regardless of approach, it’s apparent DevOps teams, like it or not, are about to be held more accountable for the provenance of every component employed across their entire application portfolio.

  • Continuous Security: The Next Evolution of CI/CD

    Continuous Security: The Next Evolution of CI/CD

    Following a wave of high-profile cyberattacks and the White House’s release of the executive order on improving the nation’s cybersecurity, how to build a successful cybersecurity program has never been so hotly debated as it is now. From SolarWinds to the Colonial Pipeline attacks, these events demonstrate that defensive measures alone cannot mitigate cybersecurity risk, and any cybersecurity program must begin where nine out of 10 breaches begin—the code. 

    The adoption of CI/CD in recent years as an extension of Agile and DevOps has enabled organizations to embrace digital transformation and ensure code is always being delivered that matches the most current business needs. Unfortunately, this has further siloed security as processes failed to keep pace. While there are a number of point solutions to address the ever-expanding domain that encompasses application security—from traditional pentesting and vulnerability scanners to monitoring of the individual components of the DevOps toolchain like containers—too many tools results in a DevSecOps “hairball” that leaves organizations inundated with data, yet without actionable information. 

    Moving Beyond Secure DevOps

    As organizations continue to evolve their delivery processes, security has found its role in secure DevOps (SecDevOps) programs to ensure the execution of security processes at every step of the software development life cycle (SLDC). By continually managing security practices, policies and debt in existing pipelines, this approach ensures that all stakeholders—from the C-suite to the developers and AppSec managers—have the information they need at every step of development to share responsibility in delivering secure software.

    However, these programs, while a good starting point, have left security requirements and checks in PDFs, Excel documents, and emails failing to capture the same benefits of security integration into the SDLC that Dev and Ops have commanded. Without SecDevOps orchestration, the information often lags the pipeline, creating new bottlenecks and uncertainty. SecDevOps orchestration gives security and development teams the confidence to know they’re following the right policies and eliminates the manual work that creates drag on the SDLC. With the automation of the application security process, enterprises get consistency and insight into their program that allows their focus to stay on shipping code while knowing it meets their organizational security standards. 

    Adding Continuous Security

    With CI/CD, organizations are able to rapidly meet the most current needs of the business as they rapidly evolve, but without a continuous approach to security as well, once again, security is siloed off. Organizations must be able to adapt their security requirements for changes both internal (changing databases, different software versions, etc.) and external (compliance requirements, changing threat landscape, etc). We need to take CI/CD one step further and also have security integrated continuously. 

    By extension, continuous security (CI/CD/CS) is the philosophy of continuously shipping software that meets the most current security standards for the business, accounting for internal and external change throughout the SDLC. 

    To effectively adopt a CI/CD/CS, organizations must focus on three key principles:

    • There is no perfect code, therefore there is no perfect security—Good application security manages cyber risk in line with overall business strategy. When you have the ability to accept risk within the risk tolerance of the businesses, you know the right times to stop, and the right times to carry on because other controls are in place. Don’t let perfection be the enemy of the shipped. 
    • Bite-sized application security—DevOps isn’t about moving fast and breaking things, it’s about moving efficiently and fixing things at the right time. Deliver the right application security information at the right time to the stakeholder responsible for executing it. This ensures better collaboration so stakeholders know where, when and with whom to direct their attention. 
    • Micro-feedback loops—Leverage orchestration to get real-time feedback on policy compliance before it creates bottlenecks down the line. This enables you to respond to changes both internal and external as quickly as possible, creating an iterative cycle of information for future decision-making. 

    By continually managing security practices, policies, and debt in existing CI/CD pipelines, this approach allows a scalable application security program to be deployed in any SDLC so it can continually evolve to always be in lockstep with today’s business.  

    Different organizations have different risks they need to account for, which means security must be aligned to business strategies and priorities in order to dynamically respond. With end-to-end integration in the SDLC, continuous security supports CI/CD to improve productivity and speed time-to-market, while reducing the risks that might impact a particular business. Software is inherently impermanent and organizations need to be able to continuously balance security, technical and business priorities to ensure they are maintaining their focus on what matters most: Delivering value to customers and shareholders. 

  • How Does IT Management Govern EverythingOps?

    How Does IT Management Govern EverythingOps?

    The number of tools engineers use to provision software architecture in the cloud is starting to get a little out of hand. There are many competing ways to do one thing. Most often, people simply adopt a new tool to solve a DevOps problem in the moment, not always considering the longevity of the solution or how other departments are handling it. This could result in fragmentation and technical debt, making it difficult to find consistency and increase speed simultaneously across all company divisions.

    I recently interviewed Jeff Kukowski, CEO, CloudBolt Software, to explore why these issues persist and how executives should approach cloud management within their organizations. According to Kukowski, many flavors of Ops now permeate large companies. Different approaches often exist per department or interdepartmental, with teams using various software stacks.

    According to Kukowski, a new frame of mind will be necessary to remain agile in the new cloud order and to address this state. Doing so will require organizations to erode false dichotomies around ownership and IT governance.

    Everything’s Going Ops

    At this point, most large suites of digital services have adopted a complex hybrid and multi-cloud modality. And many teams have embraced their own unique form of DevOps to get a handle on the management difficulties of delivering software and maintaining reliability for microservices architectures. Different groups pulling in various directions create an ongoing battle of EverythingOps, explained Kukowski.

    You can think of it as separate Ops approaches emerging around different business functions. For example, FinOps is emerging to control spending, ITOps is about delivering services, DevOps is improving release fluidity and DevSecOps aims to bring security to the forefront of the release process. Lastly, BizDevOps is about increasing observability for business outcomes.

    At a high level, CIOs have committed to digital transformation to move quicker. Yet the problem now is “battles between different Ops can easily lead to broken IT governance,” said Kukowski. This tension introduces several false dichotomies, he explained. In addition to slowing agility, a lack of DevOps unity eschews reusability, contributing to waste and increased IT expenses, said Kukowski.

    Solution: Shifting Governance Left

    There is a belief in IT that true innovation will come if you only give engineers the keys to use anything they want. While that may be true, without better leadership with regard to the basics in this new cloud order, some things can get out of control very quickly, Kukowski warned. Instead, he argued that built-in guardrails for provisioning tools are necessary. “We have too many tools—we need better frameworks to tie this together.”

    Not only would increased cloud governance help tie together disparate tooling decisions, but Kukowski argued it also can reduce the cognitive load necessary to onboard each tool. “Shifting left will increase speed—it won’t slow people down,” he said. Contrary to popular belief, he said that shifting guardrails left can have the effect of increasing speed, which may greatly outweigh the negatives of shackling developers to a single approach.

    CloudBolt predicted siloed management will shift to organizational governance around tools in the coming year. But it’s not only the tooling decisions that require forethought, “it’s the leadership and cultural approach,” said Kukowski. A common area where greater leadership is required is in tagging workloads for applications, he said. “It’s not being done well anywhere.”

    Or, consider containerization. Containers have become fundamental to most modern cloud technology stacks, yet, the cognitive load required to deploy, configure and run a contain remains quite high, explained Kukowski. Do you allow every developer to custom-code each container, or do you enable a self-service repeatable provisioning process? If standard code is not being reused, you’re not getting speed or governance, he explained. Furthermore, with green IT initiatives becoming a priority, companies should be looking at ways to reuse processes and reduce waste where they can.

    Final Thoughts: Shift Left, Automate and Reuse

    For a cloud-native company, the emphasis is constantly on speed and growth. And engineers are absolutely driving this focus and the resulting innovation. Yet, this innovation can’t come at the expense of bringing all departments onto the same level of innovation. “Innovative stuff in the cloud can’t be separated from governance, ESG and security,” said Kukowski.

    A big hurdle of tomorrow’s cloud management will be identifying and uniting these islands of automation, these pockets of tools and preferences that differ between departments. It will also require a different frame of mind across divisions. “There’s a difference between solving the problem for the task and solving the problem for reuse and speed,” explained Kukowski. Delivering on reuse and speed will require less bespoke DevOps automation and better foundations for solving future problems, he said.

    “Shift left, automate and reuse—people shouldn’t have to touch it. That’s the thinking that needs to be applied to this new cloud order,” said Kukowski.

  • 4 Ways to Combat the DevOps and Security Workforce Shortage

    4 Ways to Combat the DevOps and Security Workforce Shortage

    Most people are painfully aware that security breaches have increased in recent years, while at the same time becoming much more sophisticated in their approach. Additionally, ever-expanding application environments and continuously evolving workloads have created more opportunities than ever for attackers. What’s not so apparent to those outside of the tech bubble: The world is dangerously ill-equipped to handle the magnitude of these threats.

    Organizations may want to meet this challenge with armies of skilled technologists primed to maintain secure operations. But the reality is there is a major shortage of capable DevOps experts, especially ones with cybersecurity skills. This creates major problems for all organizations operating in modern cloud and container environments. 

    According to the cybersecurity advocacy group (ISC)2, this skills gap has noticeable, meaningful consequences for DevOps and security teams. Responses collected from more than 4,500 cybersecurity professionals around the world indicate just how severe the problem is. More than 30% of respondents said they regularly experience misconfigured applications, 29% feel that their teams are too slow to patch critical systems and 27% are unable to maintain necessary awareness of all threats active against their IT infrastructures. 

    It is clear that cybersecurity teams are not staffed to meet current—and anticipated future—demands, processes are not managed, assessment is not addressed and monitoring is incomplete. Yet, this is not just a matter of hiring more people to perform these tasks. The necessary people needed to keep DevOps environments safe simply do not exist as the role has changed faster than the workforce. 

    Time is a critical factor in security, and there can be no waiting around for a solution to appear. DevOps leaders and CISOs must do something, and fast. Fortunately, they can mitigate the burden of this skills shortage and continue moving forward with their transition to the cloud, containers and Kubernetes by taking these steps:

    1. Employ Automation

    Security and DevOps teams have to validate that security controls are actually working as intended, but also that they aren’t slowing down development efforts. Many enterprises perform manual checks to determine this, but that’s simply not scalable. Automation is the only way to do this effectively. Companies need tools that can analyze cloud activity without manual processes to understand if things are operating as expected, even in the largest deployments.

    The equalizing factor that combines speed, agility and security is found in automation. With an automated approach, cloud activity can be analyzed and interpreted and DevOps and security teams can be alerted about abnormal behavior within their cloud and container environments. This helps to address vulnerabilities and issues before they are exploited, reduce friction in the development process and ensure safe deployment. 

    For starters, DevOps teams should leverage security tools to automatically build and customize policies. The right tools, some of which can be found in open source frameworks like Falco, are built to adapt to container life cycles and integrations. DevOps teams can rely on these tools to enforce policies and to alert on issues that result from anomalous behaviors that could indicate a threat. 

    Inherent in the automation approach is the shared responsibility concept; security of cloud and container activity is put squarely into the domain of the cloud customer. They are free to operate as needed, but no organization can ignore the modern demands of speed or the necessary requirements of security. This requires that DevOps teams recognize and adapt to the needs of security oversight while security teams must act on their remit while not slowing down the development and delivery processes.

    2. Train People for the Task at Hand

    If the right people don’t exist, it’s up to security and DevOps teams to create them. Organizational training is the key to adding people with the right skills, and every organization should be looking to develop the right candidates into qualified DevOps and security experts. 

    Many of these people already can be found working as application developers or within a security function. You may find individuals who are early in their careers, looking to enhance their skill set and eager to participate in on-the-job training. Every organization should encourage mentoring by more experienced staff, but also should have formalized training programs in place to bring people up to speed on the unique needs of DevOps security. 

    Some colleges now offer specialized cybersecurity degrees or certifications. Coding schools, like the Eleven Fifty Academy in Indianapolis, for example, train students on the most current cybersecurity practices and can be a great source of talent. The United States military also offers some of the most sophisticated technology training and is also fertile ground for recruiting highly skilled security and DevOps players.

    3. Think Globally

    There is no single, prescribed way to attack or hack cloud and container environments. Approaches are diverse, and that’s why the talent responsible for security also should champion diversity. One way to do this is to look beyond your own borders for talent. As the world has embraced remote work over the past two years of the COVID-19 pandemic, more organizations than ever are equipped to bring on workers from across the globe to help them solve security and DevOps issues. 

    Think more broadly about where you can find talent and hire people who can prove their capability through tests and work samples. Not only does this deepen the pool of potential workers, but it also helps you bring new people into the fold who have different perspectives and approaches that could enhance the work you’re already doing. 

    Nearly half of the employees at the company I work for sit outside of the United States. This has drastically increased the talent pool for us. With a bit of diligence, the major barrier to hiring globally—the time difference—isn’t an issue, and you might even find it makes you more efficient.

    4. Rely on Proven Solutions

    Finally, use commercially available products to support your DevOps security needs. Building it yourself is always an option, but when it comes to security, that approach may take more time than you have; a luxury you cannot afford. 

    SaaS products are most reliable and effective in this regard, as they will scale and adapt as your team’s needs change. These tools are purpose-built for the shared responsibility model so they reduce distractions and allow you and your team to focus just on the necessary security and speed-related tasks that are important to helping you achieve your goals. Review sites, the ability to trial them and the perspectives of developer communities will also be extraordinarily helpful in guiding you to making the best decision for your organization. 

    Managing security and DevOps is never easy. With aggressive timetables and delivery deadlines, it’s easy to let the discipline required for security slip. And what makes it even harder is that we cannot hire enough people to take care of these needs. Yet, with a combination of innovative training, new perspectives on hiring and effective use of technology, any enterprise can overcome these limitations.  

  • Embracing Security by Design in Development

    Embracing Security by Design in Development

    The number of data breaches publicly reported in 2021 far exceeded the total for 2020, making 2021 a record year. With cyberattacks on the rise and bad actors and ransomware gangs demanding millions in ransom, cybersecurity has taken on new urgency.

    In addition to more sophisticated hacking techniques, the rapid pace of tech adoption during the pandemic is another contributing factor fueling cybersecurity risks. A recent survey by Forrester shows 74% of companies attribute recent cyberattacks to vulnerabilities in technology put in place during the pandemic. As companies raced to enable remote work, develop new applications and roll out new consumer-facing digital solutions, cybercriminals saw new opportunities to identify vulnerabilities and to attack. 

    Cybersecurity threats can affect every business regardless of size and every individual, regardless of who they are or where they live. Even the most protected and advanced organizations are at risk: One of the world’s biggest cybersecurity companies recently fell victim to one of the largest breaches in history. It’s time for all companies to rethink their approach to boosting security in the software development process. 

    As a nearshore development partner for businesses around the world, we have embraced a ‘security by design’ mindset to keep our clients’ builds secure. To put security first and ensure it remains at the forefront of every engagement, we adopted a parallel build systems process to improve the integrity of the code we deliver. This also reduced the overall threat of potential attacks. How did we do this? There are three key components to developing and implementing a security-by-design mindset.

    Embedded Security Expertise

    It is critical that security experts become official members of every software development team. These specialists are there every step of the way from design to delivery, finding and fixing security flaws along the development journey. Instead of being brought in at the end of the process, they are deciding on new solutions and implementing protections in real-time alongside experts in design, user experience and coding. Each plays a role and works as an integrated member of the team providing advice and suggestions during Agile cycles and sprints. 

    Predictive Analytics

    A recent survey showed that 96% of third-party applications deployed in cloud infrastructure contain known vulnerabilities. That rising risk can make it possible for bad actors to infiltrate thousands of organizations. Threat hunting tools can spot, anticipate and predict vulnerabilities in software development. Tools can automatically scan code as it is written to vet and diagnose vulnerabilities. Our team scans code while in production and reports risks and vulnerabilities and then immediately consulting with the rest of the team to work on the next secure version. 

    Continuous Learning 

    Security is changing quickly, and it’s never been more critical to ensure developers have the skills necessary to defend and protect corporate infrastructure, applications and digital solutions. With the threat landscape constantly evolving, new skills and continuous learning are required to stay ahead of the latest threats and fraud techniques. Part of our training is focused on deploying white hats, or ethical hackers, to breach our development environments and the applications we deploy. These experts then set about identifying weaknesses and helping to improve security. They also take our training to the next level and push our experts to continually learn and educate themselves on the latest threats and solutions. By upgrading their skills, security practitioners can stay ahead of cybercriminals. 

    Every day, enterprises face thousands of attacks on their systems, and malware continues to grow in frequency, volume and complexity. These attacks are not just coming from criminals looking to make a buck; there are growing fears of nation-state attacks escalating. These are often seen as the more dangerous threats to businesses. The best defense against cyberthreats is a strong offense anchored by a security by design mindset.

     

  • 2022 Will Be the Year of the Cyber ‘Shift Show’

    2022 Will Be the Year of the Cyber ‘Shift Show’

    As ransomware continues to plague organizations across industries, remote work continues and innovation brings with it new threat vectors for bad actors to exploit, 2022 is poised to be another messy year in cybersecurity.

    In July 2021 alone, organizations lost $45 million to ransomware. What’s more, ransomware costs are projected to reach $265 billion by 2031. The firm Cybersecurity Ventures predicted that “there will be a new attack every two seconds as ransomware perpetrators progressively refine their malware payloads and related extortion activities.” But ransomware isn’t the only cybersecurity concern business leaders should be thinking about heading into the new year.

    As businesses increasingly turn to digital channels like applications and websites to drive everyday business and customer interactions, those endpoints present new threat vectors for bad actors to potentially exploit. According to Okta’s 2021 Businesses @ Work report, large organizations (think AWS, Zoom, Box) deploy an average of 175 consumer and developer-facing applications, with smaller companies averaging slightly less at 73.

    What’s more, upticks in malicious activities like application cloning, credential harvesting and app spoofing will continue to cause headaches. In 2021, organizations and consumers across all sectors were forced to confront new and emerging bad actors in cyberspace. One example: The Android banking Trojan SharkBot (first discovered in October 2021), could implement overlay attacks to steal login credentials and credit card information and could intercept banking communications sent via SMS. To date, the botnet is thought to have targeted banking applications and cryptocurrency exchanges across the UK, U.S. and in Italy.

    But there is a way that organizations can bolster their cybersecurity wherewithal today to future-proof their business against the cybersecurity threats and concerns that will proliferate in the new year: It starts with “shifting left” and embracing DevSecOps within your organization.

    Bracing for Impact

    One of the ways organizations can better prepare and defend their organizations against the rise of cyberattacks to come is by adopting a developer security philosophy known as shifting left. In other words, building security into your DevOps strategy from the start. In industry circles, this practice is also known as embracing DevSecOps.

    DevSecOps involves cultivating a flexible partnership between engineers, operations and security teams to build security into all DevOps processes. Essentially, aiming to mitigate the bottlenecks of older security models on the CI/CD pipeline. DevSecOps also requires increased communication and collaboration between development, IT and security teams to ensure that security practices like testing are done in iterations throughout the code development life cycle. According to Gartner, by 2022, 90% of software development projects are projected to leverage DevSecOps practices—a 50% increase from 2019.

    But to be sustainable, cybersecurity needs to be embedded into all facets of the DevOps process—from production to testing to deployment. But even then, it’s important to remember that DevSecOps alone isn’t a security silver bullet. It’s a starting point. And as cybersecurity becomes all the more essential to bolstering business success and resiliency, it’s the least your organization should be doing in 2022.

    DevSecOps Alone Won’t Cut It

    While DevSecOps serves as a mission-critical foundation for scaling business resiliency, it won’t equip your organization to withstand the ongoing onslaught of attacks in cyberspace alone. Since most of the time, businesses are fighting nations in cyberspace—and far too often, that’s a losing battle.

    In 2022, as threat vectors widen and worsen, it will be essential for organizations to innovate with cybersecurity top-of-mind, across all facets of the development, deployment and production pipeline. Adopting DevSecOps practices across your organization, or shifting left, is one way organizations can bolster business resiliency as we head into yet another unpredictable year in cyberspace.