devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

  • ReversingLabs Applies AI to Better Secure Application Binaries

    ReversingLabs Applies AI to Better Secure Application Binaries

    ReversingLabs this week launched a binary analysis tool that uses machine learning algorithms to identify risks before and after applications are deployed.

    Erik Thoen, vice president of product management for ReversingLabs, said Spectra Assure makes use of the same core artificial intelligence (AI) technologies the company uses to discover malware within binaries to analyze the entire software package, including first-, second- and third-party components, to identify potential threats.

    Thanks to the use of AI, Spectra Assure is able to scan applications that are gigabytes in size in minutes or hours, depending on their complexity, noted Thoen.

    That approach is critical because attacks launched against applications are more often aimed at binaries that are deployed in production applications rather than the source code used to create them, he added.

    In addition, Spectra Assure can be applied to both open source and proprietary software, said Thoen. In contrast, many legacy scanning tools are designed to only surface potential issues in open source software, he noted.

    Spectra Assure is designed to be used by both producers of software and the organizations that deploy software, said Thoen. Organizations that develop software need to be able to identify any security potential issues that may have arisen during the build process, while organizations that consume software need to be assured that there are no issues that will later compromise their IT environments, said Thoen.

    ReversingLabs is attempting to fill a gap that exists in many software supply chains between when a software build is completed and deployed, said Thoen. While developers may scan source code for vulnerabilities, it’s not uncommon for changes to be made during the build process that inadvertently create vulnerabilities, said Thoen.

    It’s still not clear which teams within organizations are assuming responsibility for the software supply chain. In many cases, DevSecOps teams are securing the software supply chain, but in other instances, cybersecurity teams have been tasked to lock them down. Among organizations that consume software, responsibility for application security might be assumed by either the cybersecurity teams or a procurement office responsible for purchasing software.

    Regardless of how software supply chain security is managed, the number of attacks against them has risen sharply. A recent ReversingLabs report found there has been a 1,300% Increase in malicious packages found in open source software platforms since 2020.

    Ultimately, it’s only a matter of time before more stringent regulations force the software supply chain security issue. A recent executive order issued by the Biden administration requiring federal agencies to secure software supply chains is a harbinger of stricter controls that enterprise IT organizations must implement. DevSecOps teams, in the meantime, have an opportunity to revisit the workflows that were created in an era where developers tended to overly trust the integrity of software components downloaded from open repositories.

    Of course, it may require a catastrophic event to truly galvanize organizations into action, but one way or another, application security is going to improve. The only issue remaining to determine is how expensive a proposition that will be given the potential fines that are likely to be one day levied.

  • Software Development in the Age of AI: How to Balance Quality and Speed

    Software Development in the Age of AI: How to Balance Quality and Speed

    There’s no mistaking the reality of AI’s influence. Across industries, businesses are calling on tech workers to make the most of this transformative technology as demand skyrockets and companies race to overcome the competition. A flagging economy only pushes expectations for AI use—in software especially. To contend with arduous workloads, 92% of developers are already using AI code generators, according to GitHub. That’s an overwhelming majority, not to mention that this usage is poised to continue generating steam.

    In light of this, we must ask ourselves a critical question: How can businesses ensure developers retain the quality of their AI-generated code? AI is a useful complement to human developers to maximize their time and allow them to focus on projects best suited to their skill sets. That said, companies have to put safeguards in place to harness the technology, not just for boosting developer productivity but also for quality outputs.

    AI Can’t Replace Human Developers

    AI code generators are a useful tool for a developer’s toolbox. Efficient, easy to use, and helpful (in a fairly rudimentary way in these early AI days), they give developers the ability to outsource some code-writing, which helps alleviate mounting demands as companies expect them to produce massive amounts of code — and fast. As most developers continue to buy into AI for productivity benefits, though, comes the responsibility to gut-check what these AI tools produce.

    There are multiple limitations and risk considerations when it comes to AI-generating code. Lack of source knowledge and context is one of them. AI pulls from what it’s taught (i.e., past data, natural language processing, machine learning), meaning it combines too many sources to trace specific pieces of coding back to one place; it’s impossible to trace the code back to a single developer or project. Security, too, becomes an issue; you can’t guarantee that what is produced is safe or clean as is. And, finally, AI doesn’t check for quality, which increases the likelihood that the code will be difficult and costly to maintain. All this ladders up to the mounting technical debt companies are already contending with.

    Developers can’t assume that any AI-generated code is of quality to be put directly into production. Human workers must review code thoroughly to ensure it meets clean code attributes–secure, reliable and maintainable. Ignoring these tenets puts businesses at risk of falling victim to the trillion-dollar cost of bad software. That said, there are still undeniable benefits to using AI in a coding environment that make it an invaluable tool for any company that wants to stay at the top of their software game.

    Working Responsibly With AI in Software Development

    Despite its potential shortcomings, when used safely and effectively alongside a clean code solution, AI brings a tremendous opportunity to the software space that has already made it a key tool for developers as their workloads and demands mount. For one, AI has the incredible ability to churn out code at a speed that far outpaces its human counterparts. This tech can complete tedious work that may take valuable time out of a developer’s day in a matter of seconds. AI can not only move a project forward at a faster rate, but its quick coding capabilities can also give developers a jump start on their projects and help them figure out where to begin.

    While the source of AI’s knowledge base can present a challenge, the vastness of that knowledge is a benefit. As long as a developer can input their preferred language and their specific needs, AI can share the best approach to solving a problem. Its algorithmic assistance can help lead a developer through parts of their projects step by step. This also alleviates the burden of research from developers, who can spend less time checking for accuracy than they would trying to understand different programming concepts or code snippets outside their area of expertise. AI can also handle the slog of documentation, which can not only bring clarity to what didn’t work during the development process but reduce time to delivery overall.

    Developers who don’t harness AI do so at the risk of falling behind the competition as this tech becomes such a vital piece of everyday work in software. But there’s no mistaking the fact that to best incorporate AI, developers still need to ensure its accuracy before any code generated by AI makes it to production.

    GenAI Requires Automated Tools as Safeguards

    As I previously said, developers can’t assume that any AI-generated code is clean and fit for production. That means human skills are still required to check the output. However, this kind of work can often fall to developers or DevOps, and having human workers check code on their own creates an incredible workload that can even negate the use of AI in the first place.

    The best way for companies to mitigate this and mitigate technical debt is to implement automation in the part of the process that scans and monitors AI-generated code. But that can’t be done without developer buy-in. Those creating the software are the people who will best understand the development process as they work through it day in and day out, so their input is required to make the most out of automation.

    There are developer tools that can handle this kind of work while still including developers in the process. For example, introducing code-scanning into the CI/CD process can not only help continuously monitor AI-generated code for bugs and issues, allowing developers to focus on other more challenging aspects of their projects, but it also gives them insight into errors and allows for speedier resolutions. These tools aren’t necessarily new to development, but their ability to identify bugs can help developers prioritize other aspects of the process, particularly as the amount of code reaches exponential levels compared to decades ago with the introduction of GenAI.

    Static application security testing (SAST) also allows for the identification of security vulnerabilities that can potentially arise from AI-generated code. This is critical in the software development lifecycle (SDLC) so developers can spot vulnerabilities before the code goes into production. AI-generated code is only as strong or secure as that source, and since it’s not entirely possible to verify, developers need to take every precaution available to avoid security issues that rack up costs in the long term.

    The vital part of using these tools is ensuring they’re integrated into the process in a way that makes sense for developers rather than creating additional work and headaches with a cumbersome process that doesn’t fit the way teams think and work. But, the need to check AI-generated code shouldn’t be underestimated. Developers can’t simply trust what they’re given. By including a level of automation within the development process—and doing so early and often—developers are in a position to produce better-quality, more secure software to push a business forward.

    Effective Adoption of AI Will Encourage Business Growth

    While it’s difficult to predict exactly where AI will take us in the years to come, it’s equally undeniable that it will play a critical part in the future of software development. Yes, AI is already helping to streamline processes and letting developers prioritize the tasks that best take advantage of their skills. But, as noted above, that doesn’t mean the code output is entirely safe, secure or accurate. Developers still need a level of automation to deliver code that best takes advantage of AI while keeping their workload manageable and their focus on other parts of the development process.

    With the right guardrails in place, developers can guide AI to create the kind of clean, secure, and reliable code that aids businesses rather than create costly problems for them, both now and down the line. Human skills, with a boost from AI, plus code scanning safeguards, give organizations the winning combination to put themselves in the best possible place to succeed in a rapid, fierce competitive landscape of digital business.

  • Veracode Report Shines Spotlight on Massive Application Security Debt

    Veracode Report Shines Spotlight on Massive Application Security Debt

    An analysis of more than a million applications published today by Veracode, a provider of a software supply chain security platform, found 42% of applications contained flaws that remained unfixed for longer than a year.

    Based on 1,553,022 dynamic analysis scans and 11,429,365 static analysis scans, the report noted that those applications with that level of security debt were found in 71% of the organizations maintaining these applications. Nealy half of organizations (46%) have persistent, high-severity flaws that constitute ‘critical’ security debt. Approximately 63% of applications have flaws in first-party code, while 70% contain flaws in third-party code imported via third-party libraries.

    Remediation rates also vary by flaw type. Fixing third-party flaws takes 50% longer, with half the known flaws fixed after 11 months, compared to seven months for first-party flaws.

    Collectively, the scan run by Veracode produced 96 million raw static findings, four million raw dynamic findings and 12.2 million raw software composition analysis findings.

    Chris Eng, chief research officer for Veracode, said it’s clear too many organizations are kicking application security flaws down the road only to find they don’t have the time to address them properly. Meanwhile, cybercriminal syndicates and nation-states are becoming more adept at exploiting these flaws with each passing day, he added.

    In general, there is a lot more focus on software supply chain security in the wake of an executive order issued by the Biden administration that requires federal agencies to identify and remediate security flaws. However, the pace at which enterprise IT organizations are following the lead of the Federal government varies widely. Only a relatively small percentage of the vulnerabilities that exist in applications running in production environments are being exploited, so many enterprise IT teams have yet to prioritize the issue.

    However, as more cybercriminals acquire the skills required to discover and exploit those vulnerabilities, it’s only a matter of time before a major application security crisis ensues, noted Eng.

    Theoretically, at least, artificial intelligence (AI) should one day soon make it easier to discover and remediate vulnerabilities, but it’s just as likely cybercriminals will use the same capabilities to achieve their own nefarious ends. In fact, it’s largely a race against time before existing application flaws are exploited using AI-based tools and techniques. Application development teams that fix flaws the fastest reduce critical security debt by 75%, from 22% of applications to just over 5%, the Veracode report noted.

    Naturally, it’s less costly and simpler to fix security flaws before applications are deployed in a production environment, so the more organizations embrace DevSecOps best practices on the front end, the lower the overall security debt becomes, noted Eng.

    It’s not clear whether organizations might decide to replace or consolidate applications to reduce their security debt, but given the overall lack of cybersecurity expertise among application developers, the current level of security debt is likely to continue to rise. The challenge, of course, is that as the security debt rises, the number of developers available to address, unfortunately, remains comparatively constant.

  • Squaring the Circle: How to Make Public APIs Private

    Squaring the Circle: How to Make Public APIs Private

    APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

    APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

    Day 2 API Security Solutions and Snowflakes

    This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

    Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

    A Difficult Race to Win

    Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

    The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

    Why Not Avoid the Race?

    So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

    Zero-Trust API Networking Needs to be Built for APIs

    To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

    Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

    There are usually three reactions to the diagram above:

    1. OK, tell me how it works. See below.
    2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
    3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.

    How Zero-Trust API Networking Works

    Here are the four pillars of zero-trust API networking:

    1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
    2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code: 
    3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
    4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.

    The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:

    • Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
    • Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
    • Extensibility. Software-only, cloud-native architectures. Preferably open source based.
    • Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
    • Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
    • Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
    • Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.

    Zero-Trust API Networking

    While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

    Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.

  • Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

    Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

    Legit Security today announced it has added the ability to detect when developers use generative artificial intelligence (AI) tools to write code to its application security posture management (ASPM) platform.

    The ASPM platform developed by Legit Security already has discovery capabilities for application secrets, for example, enabled by sensors that are now being extended to include generative AI tools.

    Legit Security CTO Liav Caspi said the overall goal is to allow DevSecOps teams to identify who uses these tools to write which types of code. Each DevSecOps team can then decide how stringently to enforce policies to either ban or limit usage of those tools, he added.

    There is no doubt that generative AI tools are increasing developer productivity, but the large language models (LLMs) that provide the ability to generate code were trained using examples of code of varying quality collected from across the web. Much of that code either contains known vulnerabilities or is simply inefficient, which can manifest itself in the output surfaced by a generative AI platform.

    The Legit Security ASPM platform, in addition to identifying generative AI tools being used in real-time, can also be employed to scan the LLM itself to identify security risks such as prompt injection and insecure output handling. Unfortunately, most cybersecurity teams are unaware of the extent to which application code generated by a machine might be insecure, so it currently falls to leaders of DevSecOps teams to determine what is an acceptable use of these tools. It may be perfectly fine to rely on a generative AI tool to create a script that will be used for an internal-facing application. However, using the same tool to write business logic that will be exposed to the internet may not be especially prudent.

    It’s not clear how much of the code finding its way into software builds is being generated by a machine versus a human. In the longer term, the goal is to be able to identify that code by, for example, detecting substantial changes in the way code is normally written by a human developer, said Caspi.

    Of course, while an ASPM may detect usage of generative AI tools that are connected to a corporate environment, there are still plenty of opportunities for developers to use these tools offline to create code that can later be added to a build using a code check-in tool. After all, many developers have used various shadow IT tools to write code for decades. Regardless of who or what wrote that code, however, it should still be reviewed.

    In the meantime, the overall size of the codebase that DevSecOps teams will need to manage and secure will only exponentially increase as developers become more productive. Hopefully, more AI capabilities will soon be embedded into DevOps platforms to further automate the management of software builds at a time when many DevOps teams were already finding themselves overwhelmed even prior to the rise of generative AI.

  • Akamai Launches Gecko Edge Computing Services

    Akamai Launches Gecko Edge Computing Services

    Akamai Technologies today launched an initiative that promises to make it simpler to centrally manage and deploy application workloads on edge computing platforms.

    Shawn Michels, vice president for product management for cloud computing Akamai, said a Generalized Edge Compute (Gecko) offering leverages the global points of presence (PoPs) that Akamai uses for its content delivery network (CDN) to now deploy application workload managed via the Linode cloud service the company acquired in 2022.

    At the core of this offering is a set of virtual machines that enable a full stack of application software to be deployed in an edge computing environment to eliminate latency that would otherwise be encountered when transferring data to a cloud computing environment. The ultimate goal is to provide IT organizations with a federated set of services they can employ to process data where it makes the most sense based on performance requirements, said Michels.

    For example, applications infused with artificial intelligence (AI) will need to be able to invoke enough compute resources to run inference engines at the edge, while other less compute-intensive application workloads are best deployed in cloud computing environments, he noted.

    Michels added that rather than locking IT teams into a specific architecture, Akamai is committing to meeting IT organizations where they are, including adding support for containers running on Kubernetes clusters in its PoPs later this year.

    Akamai has more than 4,100 points of presence around the globe. With the acquisition of Linode, Akamai added a set of cloud computing services to compete directly against hyperscalers such as Amazon Web Services (AWS), Microsoft and Google by making cloud services available at a lower cost at a time when more organizations than ever are concerned about the total cost of IT.

    In its first phase of Gecko, Akamai will provide access to virtual machines in 100 locations by the end of the year. Akamai has already deployed Gecko servers in Hong Kong SAR; Kuala Lumpur, Malaysia; Querétaro, Mexico; and Johannesburg, South Africa, as well as in cities without a concentrated hyperscaler presence, including Bogotá, Colombia; Denver, Colorado; Houston, Texas; Hamburg, Germany; and Marseille, France. Deployment of a tenth Gecko region this quarter is planned for Santiago, Chile. Akamai is committing to adding hundreds of cities to its global cloud computing footprint over the next several years.

    In the longer term, Akamai also plans to add automated workload orchestration to make it easier for developers to build applications across hundreds of distributed locations.

    More workloads than ever are being deployed at the network edge as IT teams look to deploy software closer to the point where data is being created and consumed. That will require extending the reach of existing DevOps workflows to edge computing environments that will be based on everything from x86 and Arm processors to graphical processor units (GPUs).

    The challenge, as always, will be finding a way to effectively manage those workloads when the IT teams responsible for them are often physically located thousands of miles away.

  • Improve Efficiency With Smaller Code Reviews

    Improve Efficiency With Smaller Code Reviews

    In software development, code review plays a significant role in helping detect issues in your application’s source code early and promote collaboration among your team members. Breaking down code reviews into more manageable portions can yield great benefits. Review cycles are shorter and more convenient to comprehend when they are smaller. In other words, smaller reviews are easier to comprehend and provide feedback cycles. As a result, we can reduce development, deployment and debugging times while reducing the scope of change in each iteration.

    This article presents a discussion on code reviews, why they are important, their benefits and why smaller code review cycles are more effective than larger ones.

    What is Code Review?

    Code review is defined as a software development process which involves reviewing code written by other developers. As part of the development process, it aims to improve code quality, ensure compliance with standards and identify and fix problems early on. Code reviews play a role in software development as they help catch errors before they turn into significant issues.

    Peer reviews allow developers to detect errors or defects in each other’s code. By reviewing each other’s code, developers are able to identify bugs and flaws in the code. It helps deliver code that is secure and sustainable, adheres to standards and detects and resolves problems early in the development life cycle.

    This can either be a formal process, where code is systematically evaluated according to a checklist or set of guidelines, or an informal process, where code is reviewed ad hoc. Code review can be performed by the same developers working on the code or by other developers with expertise in the relevant domain or technology.

    ​By engaging in the exchange of feedback and actively participating in code reviews, we can ensure that the code is well-organized, easy to comprehend, adapt and extend over time. To be effective, it’s essential that everyone on the team is on the same page when it comes to their expectations and goals regarding these reviews.

    Here are the key benefits of code review at a glance:

    • Identify bugs and issues
    • Improve code quality, consistency and maintainability
    • Enforce coding standards
    • Foster team collaboration
    • Promote knowledge sharing

    Best Practices of Code Review

    Here are some of the best practices you should follow to improve your code review process:

    • Review small units of code
    • Set clear objectives and guidelines
    • Involve multiple reviewers
    • Provide constructive and respectful feedback
    • Use code review tools
    • Prioritize high-risk areas
    • Balance attention to detail with time efficiency
    • Encourage collaboration and learning
    • Set realistic deadlines
    • Follow up and close the loop

    Automating the Code Review Process

    Automated code reviews can help you enhance collaboration amongst your team and reduce the time spent in each cycle. Your developers can improve code quality and maximize productivity by automating the development workflow.

    Here are the key benefits of automating the code review process:

    • Enhances code quality
    • Improves productivity
    • Enhances code quality
    • Improves collaboration
    • Fosters learning opportunities

    The Problem With Large Code Reviews

    The traditional approach to code review often involves reviewing large chunks of code in a single session. Although this approach is initially efficient, it can lead to multiple problems. You will need more effort and spend more time reviewing large chunks of code. If code reviews are extensive and take longer to complete, it can often result in decreased attention to detail. Due to this, the likelihood of missing crucial errors and reviewer fatigue will increase, resulting in delays in feedback and completing the code review process.

    The Benefits of Smaller Code Reviews

    When the code review cycle is small, it becomes easier to track deployment changes easily. Smaller code reviews continuously improve development, deployment and debugging times and reduce the radius of a change set. As a result, it promotes faster deployment and helps identify issues easily and early in the software development life cycle.

    Once a code review cycle is complete, the code goes through many steps before it finally reaches the production phase. Monitoring the application’s performance and detecting bugs (if any) is much easier when you make only minimal changes to your code. When the changes are small, it is easier to track the application’s behavior and detect bugs.

    Here are some benefits of adopting smaller code reviews:

    Focused Review

    Reviewing smaller chunks of code enables you to analyze the code in a more focused and in-depth manner. This helps reviewers focus on specific functionality or components, leading to more accurate feedback.

    Reduced Cognitive Load

    Limiting the amount of code to review reduces cognitive overload for both developers and reviewers. Smaller code review cycles can be more efficient because they break down the review process into more manageable chunks. As a result, you’ll be able to evaluate code quality in a much more effective and efficient manner and identify potential issues or improvements more easily.

    Faster Feedback Loop

    Smaller code reviews can significantly speed up the feedback loop in the development process. Hence, feedback cycles will be faster, i.e., you will be able to receive feedback faster, resulting in quicker iterations and faster software delivery. The smaller the review, the easier it is to digest and the faster the feedback cycle.

    Enhanced Collaboration

    Smaller code reviews allow for more focused discussions and collaboration between reviewers and developers. Most importantly, since you can handle concerns effectively and efficiently, you can engage in more productive discussions. The efficiency and effectiveness of code reviews improves when the expectations of all stakeholders are aligned.

    Measuring Success

    To measure the success of smaller code reviews, consider the metrics and approaches given below:

    Defect Detection Rate

    This is a measure of the number of defects or issues identified during a code review cycle relative to the number of defects found later in testing or in the production environment. Note that a higher defect detection rate indicates you’re able to detect defects effectively.

    Review Efficiency

    Calculate the time it takes to review a chunk of code to understand the pace and efficiency of the code review process.

    Feedback Quality

    Assess the quality of the feedback provided during reviews, such as checking if the feedback is constructive, clear and actionable. Note that if the feedback is of high quality, it would typically yield better code improvements and learning opportunities for your team.

    Cycle Time

    The duration of the code review process is an indicator of efficiency. A shorter cycle time suggests an efficient review process, but quality should not be compromised.

    Automated Checks Integration

    Evaluate how effectively automated tools are integrated into the code review process to detect common issues and reduce the manual effort required in reviews.

    Knowledge Sharing

    Assess how well the code review process facilitates knowledge sharing and cross-team learning. This can be observed through the diversity of reviewers and the nature of the discussions in the review process.

    Bug Rates Post-Release

    Monitor the incidence of bugs or issues in the code post-release. A decrease in this rate can indicate that the code review process is effectively catching and addressing potential problems before release.

    Conclusion

    Code review helps produce code that is highly performant, scalable, secure and compliant with the recommended standards. Code reviews can make the codebase easily understood, flexible and scalable. A collaborative approach to code review can yield several benefits, such as promoting a culture of continuous development and learning, maintaining an organized codebase with clean code and clear structure, helping detect and resolve issues quickly, etc.

  • Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    A survey published today finds 91% of respondents work for organizations that have experienced a software supply chain incident in the past 12 months.

    The survey polled 368 IT, cybersecurity and application developer professionals responsible for application security in North America and was conducted by the research firm Enterprise Strategy Group (ESG) on behalf of Data Theorem, a provider of an application security platform. The survey found zero-day exploits of vulnerabilities within third-party code (41%) were the most common attack vector, followed closely by misconfigured cloud services (40%), vulnerabilities in open-source software and container images (40%), stolen secrets/token/passwords (37%) and breaches of application programming interfaces (APIs) (35%).

    The biggest areas of impact of those breaches are identified as cryptojacking (43%), inability to meet service level agreements (41%), malware infestation (39%), unauthorized access (39%), stolen developer credentials (37%), data loss (37%) and the levying of fines (37%).

    Despite these issues, however, nearly three-quarters (74%) of respondents claimed their organization has “robust” software supply chain security capabilities even though a similar percentage said they are making significant investments in software supply chain security, with an additional 25% making moderate investments. More than three-quarters (77%) said they have increased their effort to secure third-party software components and container images in the wake of an attack. The top two areas of focus are new detection rules/analytics (33%) and the adoption of multifactor authentication (MFA) (33%).

    Top investment priorities over the next 12 to 18 months include scanning open source code components and third-party libraries for vulnerabilities (44%), followed by discovering and inspecting APIs in source code (39%), using composition analysis tools to create software bill of materials (SBOMs) (38%) and applying runtime API security controls (33%).

    The most widely used tools today are automated open source package risk management (34%), static application security testing (SAST) tools (34%), vulnerability scanning of cloud services (32%), automated security as code policy enforcement (31%) and dynamic application security testing (DAST) tools (31%).

    Data Theorem COO Doug Dooley said while the survey makes it clear progress is being made, there is still a lack of urgency. It may require additional high-profile breaches to create a large enough public outcry to pass the legislation that is going to be required to address software supply chain security issues more vigorously. In fact, 83% of respondents noted industry regulations are a key driver to ensure they create accurate SBOMs.

    In general, the survey finds nearly two-thirds of respondents (65%) have more than 50 Git repositories, with 40% reporting that more than half of their code is composed of third-party software. Half of respondents (50%) said they expected that to rise to more than half in the next 12 months. Well over half (58%) noted more than 30% of their code would be of open source software.

    Only 43% report they are completely confident that their developers are only using secure open source software. On the plus side, 90% are prioritizing efforts to shift security left to developers.

    Overall, 86% said it’s critical or important to know the composition/inventory of application code in use, where code is stored, and who has access to code components connected to their code. A total of 88% also noted it’s critical or important to have accurate inventory of their third-party APIs and cloud services.

    The one thing that is certain in the months ahead is that cybercriminals will put software supply chain security to the test. The challenge and the opportunity now, regardless of what regulations are ultimately passed, is to thwart those attacks before the damage inflicted ultimately forces lawmakers to act in ways that make software development a lot more difficult than it already is.

  • GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian Allies With CyberArk to Better Protect App Secrets

    GitGuardian this week revealed it has allied with CyberArk to streamline secrets detection and management by making it easier to share insights.

    Ziad Ghalleb, product marketing manager for GitGuardian, said the two companies have integrated their respective platforms using open source software that integrates GitGuardian Secrets Detection and CyberArk Conjur Cloud, a software-as-a-service (SaaS) platform for managing and rotating secrets as needed.

    In addition, CyberArk Conjur Cloud is now integrated with HasMySecretLeaked, a tool for discovering if a specific secret has been exposed on GitHub. That capability enables DevSecOps teams to periodically cross-reference secrets and credentials against a private database of secrets known to have been publicly exposed.

    GitGuardian claims to have uncovered more than 20 million publicly exposed secrets on the GitHub repository. While GitGuardian provides tools to discover exposed secrets, organizations rely on the CyberArk platform to manage secrets and remediate issues that arise when they are left exposed.

    The immediate challenge is to find ways to integrate secrets detection within the context of larger ecosystems, said Ghalleb. In the longer term, GitGuardian is working toward embedding its tool into integrated development environments (IDEs) to surface exposed secrets as developers build software, said Ghalleb.

    Naturally, there is a lot more focus on secret detection, and secrets management is getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. For many organizations, however, it’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is shifting left toward developers and the DevOps teams that support them.

    Unfortunately, too many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Many forget to remove those secrets before an application is deployed in a production environment. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all.

    In the meantime, cybercriminals are becoming more adept at using scanning tools to discover secrets and then exploiting them to compromise applications after they have been deployed.

    Hopefully, DevOps teams will implement DevSecOps best practices to address those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.

    It’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are drafting legislation that would hold organizations much more accountable for the security of the applications they build and deploy. As more fines are eventually levied, the tolerance for leaving secrets exposed in applications is only going to decline.

    Secrets discovery and management is, of course, only one aspect of application security, but the more these issues are addressed before applications are deployed the less stressful cybersecurity becomes.

  • How Can DevOps Teams Use Customer Intelligence Data?

    How Can DevOps Teams Use Customer Intelligence Data?

    Customer intelligence involves collecting and analyzing data about customers’ behaviors, preferences and needs. It helps businesses understand their customers better and tailor their products and services to meet customer demands. The data is gathered from various sources, such as customer feedback, web analytics, social media, purchase history and software usage metrics. The insights drawn from customer intelligence can be used to inform business strategy, product development and marketing efforts.

    The goal of customer intelligence is to create a detailed understanding of the customer’s needs, preferences and habits. This information can be used to predict future behavior, improve customer service and drive sales. For instance, if a software company knows that a particular customer segment mainly accesses their software on mobile devices, the organization can improve their mobile support or create dedicated mobile applications for that customer segment.

    How Can DevOps Teams Use Customer Intelligence Data?

    There are several ways that a DevOps team can leverage the data gathered from customer intelligence.

    Prioritizing Feature Development Based on Customer Feedback

    When developing new features, it’s useful to analyze customer feedback to understand what features customers find most valuable and prioritize those for development. For instance, if feedback suggests that customers want a more intuitive user interface, the team can prioritize UI improvements.

    By focusing on the features that customers find most valuable, DevOps teams can improve the usability and functionality of their products. This can lead to higher customer satisfaction and loyalty and, ultimately, increased sales. Additionally, prioritizing feature development based on customer feedback can help DevOps teams avoid wasting time and resources on features that customers don’t value.

    Tailoring UX and UI Design Based on Customer Preferences and Behaviors

    By analyzing data on how customers interact with their products, teams can identify pain points and areas for improvement. For example, if data shows that customers are having difficulty navigating the website, the team can redesign the navigation to make it more user-friendly. 

    Alternatively, if customers abandon their shopping carts at a certain point in the checkout process, the team can investigate and make necessary improvements.

    Using Customer Data to Drive Personalization and Customization Features

    Personalization is about tailoring the customer experience to the individual user, while customization is about giving customers the ability to tailor the product or service to their specific needs.

    For instance, by analyzing data on a customer’s browsing and purchase history, a team could develop a feature that recommends products based on the customer’s past behavior. Or, if a customer frequently purchases a certain type of product, the team could create a feature that allows the customer to customize that product to their liking.

    Leveraging Predictive Analytics to Forecast Future Customer Needs and Trends

    Predictive analytics involves using historical data to predict future events. In the context of DevOps, this could mean using customer data to forecast future customer needs and trends.

    For example, if data shows a growing interest in eco-friendly products, the team could anticipate this trend and start developing more eco-friendly products. Predictive analytics can also help teams identify potential issues before they become problems, allowing them to address those issues and improve the customer experience proactively.

    Best Practices for Effectively Using Customer Intelligence in DevOps

    Here are some best practices that DevOps teams can use to make the most of their customer intelligence data.

    Integrate Customer Feedback Early and Often

    Customer feedback from surveys, social media, and customer service interactions provides invaluable insights into what customers need, their pain points, and their preferences.

    By integrating this feedback into the DevOps process, teams can better understand customer needs and develop products or services that address those needs effectively. Early integration of customer feedback allows teams to pivot and make changes more swiftly, thus saving time and resources.

    It’s also important to obtain feedback regularly. Customers’ tastes and preferences evolve continuously, and their feedback reflects those changes. Feeding frequent customer intelligence into the development process ensures the DevOps team’s work stays aligned with the shifting customer landscape.

    Leverage Analytics Tools

    Analytics tools can help DevOps teams sift through large volumes of customer data and extract actionable insights. These insights can then be used to inform decision-making and drive innovation.

    Some tools excel at data visualization, helping teams understand complex datasets through graphs and charts. Other tools excel at predictive analytics, helping teams forecast future trends based on historical data.

    Choosing the right analytics tool depends on the specific needs of the DevOps team and the nature of the customer intelligence data they have at their disposal. The key is to leverage its capabilities fully to extract the most value from the customer intelligence data.

    Ensure Data Quality and Relevance

    Not all data is created equal, and if it is poor quality or irrelevant, it can lead to misguided decisions and wasted resources.

    Data quality refers to the accuracy, completeness, consistency, and reliability of the data. DevOps teams should implement robust data quality checks to ensure that the customer intelligence data they’re using is of high quality.

    Data relevance, on the other hand, refers to the data’s applicability to the task at hand. Not all customer intelligence data is relevant to every DevOps project. Teams need to carefully select the data that is most relevant to their specific project and ignore the rest.

    Balance Quantitative with Qualitative Data

    While quantitative data provides hard numbers and concrete facts, qualitative data offers deeper insights into customer attitudes, perceptions and behaviors.

    Quantitative data can help DevOps teams identify trends, measure performance, and track progress over time. However, it often fails to explain why certain trends are occurring or why performance is changing. 

    It also can help DevOps teams understand the reasons behind the numbers. It can provide insights into why customers behave the way they do and what they truly think and feel about a product or service. Balancing quantitative with qualitative data gives DevOps teams a more holistic view of the customer landscape, enabling them to make more informed decisions.

    Cross-Functional Collaboration

    Customer intelligence data is valuable for all teams across the organization, not just DevOps. By collaborating with other teams, such as marketing, sales and customer service, the DevOps team can gain additional insights and perspectives. 

    Cross-functional collaboration also fosters a culture of data-driven decision-making across the organization. When all teams use customer intelligence to inform their work, the organization as a whole becomes more customer-centric, agile and innovative.

    Conclusion

    Successfully using customer intelligence data in software development allows teams to remain responsive to customer needs and increase the value of their products. DevOps teams need to integrate customer feedback early and often, leverage analytics tools, ensure data quality and relevance, balance quantitative with qualitative data,and foster cross-functional collaboration. By following these best practices, DevOps teams can use customer intelligence data to drive innovation and create products and services that truly resonate with customers.

    Image source: Josh Sortino via Unsplash