staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • A Seven Point Checklist for Getting SAST Right

    A Seven Point Checklist for Getting SAST Right

    With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

    In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

    Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

    With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

    1. Deep Language Support: C/C++, Java, C#, etc.

    Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

    2. Compiler and Embedded OS Platform Compatibility

    Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

    3. Actionable Alerts

    For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

    4. Built-In DevOps Integration

    The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

    5. Flexible Deployment

    Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

    6. Developer-friendly UI

    Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

    7. Standards

    Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive),  DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

    Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

  • GraphQL Documentation Generators: How They Work and Why They Matter

    GraphQL Documentation Generators: How They Work and Why They Matter

    GraphQL is an open source query language developed by Facebook that provides a more efficient, powerful and flexible alternative to traditional REST APIs for fetching and manipulating data over the web. It allows clients to specify the shape and structure of the data they need and receive exactly that, no more and no less.

    Unlike REST APIs, which expose fixed endpoints for specific resources, GraphQL enables clients to construct complex queries that describe the exact data they need, with the server returning only that data in response. This allows for more efficient network usage and improved integration with CI/CD pipelines, as changes to the data requirements can be easily made without breaking existing clients.

    GraphQL also offers real-time capabilities through subscriptions, allowing clients to receive live updates as data changes on the server and supports a range of programming languages and platforms through a variety of libraries and tools.

    What are Documentation Generators?

    Documentation generators are tools that automatically create documentation from source code, making it easier for developers and other stakeholders to understand and work with a codebase. These tools parse the source code and extract information about the structure, behavior and dependencies of the code and use this information to generate documentation in various formats, such as HTML, PDF or markdown.

    Documentation generators can help improve the quality of code documentation by automating the process and reducing the risk of errors or omissions. They can also save time and effort for developers, as they can quickly generate documentation without having to write it manually.

    There are different types of document generation techniques, each with its own advantages and use cases. Let’s discuss some of them:

    • Batch generation: A generic technique that involves generating documents in bulk using a set of rules and templates. It’s commonly used for generating reports, invoices and other similar documents that follow a specific format. Batch generation can save time and effort by automating the document creation process and reducing errors.
    • Text block correspondence: Involves creating documents based on pre-defined text blocks. These text blocks can be customized and combined to create different types of documents, such as contracts, letters, and proposals. Text block correspondence is commonly used in document assembly tools, which allow users to create documents by selecting the appropriate text blocks and filling in the necessary information.
    • Forms: A type of document generation that involves creating web-based forms that users can fill out to generate documents. Forms can be used for a variety of purposes, such as generating applications, registrations and surveys. Forms can be customized to match the specific needs of the organization or business.
    • Documentation synthesis: Involves combining data from multiple sources to create comprehensive documentation. This technique is commonly used in software development where documentation needs to be created for different parts of the system. Documentation synthesis can save time and effort by automating the documentation process and ensuring consistency across different parts of the system.

    Documentation Generators for GraphQL

    Documentation generators for GraphQL work by analyzing the GraphQL schema and generating documentation based on the information in the schema. The GraphQL schema defines the structure of the data and the available operations, and it serves as the basis for generating documentation.

    Documentation generators typically follow a similar process:

    • Analyze the schema: The documentation generator analyzes the GraphQL schema to identify the available types, fields and operations.
    • Generate documentation: Based on the information in the schema, the documentation generator generates documentation in a specific format, such as HTML, markdown or PDF. The documentation typically includes information about the available types, fields and operations, as well as any associated documentation, such as descriptions or examples.
    • Include additional information: Some documentation generators may also include additional information, such as query examples, error handling information or performance considerations.
    • Update the documentation: The documentation generator can be run periodically to update the documentation based on changes to the GraphQL schema.

    Documentation generators for GraphQL are typically designed to be flexible and customizable so that developers can customize the generated documentation to meet their specific needs. For example, developers may be able to customize the format of the documentation, include additional information or exclude certain information.

    Documentation Generators for GraphQL: Why They Matter

    Documentation generators for GraphQL are important tools for DevOps teams for a number of reasons:

    • Efficiency: Documentation generators automate the process of creating and updating documentation for GraphQL APIs. This can save DevOps teams a significant amount of time and effort, particularly when working with large or complex APIs.
    • Consistency: Documentation generators can help ensure that documentation is consistent with the GraphQL API and up-to-date. This can help reduce confusion among developers and other stakeholders and improve the overall quality of the documentation.
    • Collaboration: Documentation generators can help improve collaboration among DevOps teams by making it easier to share and review documentation. This can help ensure that everyone has access to the most up-to-date information and that documentation is reviewed and approved by all stakeholders.
    • Accessibility: Good documentation is essential for developers who are working with GraphQL APIs, and documentation generators can help ensure that documentation is clear, concise, and accessible. This can help reduce the learning curve for new developers and make it easier for developers to understand and work with the API.
    • Scalability: Documentation generators can help DevOps teams manage the documentation of large or complex GraphQL APIs, making it easier to keep up with changes and ensure that the documentation is accurate and up-to-date.

    Conclusion

    In conclusion, by automating the documentation process, documentation generators can save time and effort for developers, reduce the risk of errors and inconsistencies in the documentation and provide a common source of truth for different teams and stakeholders. In addition, documentation generators can help DevOps teams better understand the API, improve collaboration and communication and speed up development cycles. 

  • Postman Releases Tool for Building Apps Using APIs

    Postman Releases Tool for Building Apps Using APIs

    Postman today made generally available a visual tool infused with artificial intelligence (AI) that makes it simpler to build software by invoking application programming interfaces (APIs) found on its network.

    Shamasis Bhattacharya, chief software architect for Postman API, said Postman Flows makes it possible to use a low-code tool to build software using tens of thousands of APIs that can be found on the Postman API network.

    The goal is to reduce the amount of toil required to build applications of moderate to medium complexity in a way that doesn’t require developers to have deep programming expertise, he added.

    Instead, developers are presented with “blocks” that they can drag and drop to create an application and deploy the associated workflows. Postman Flows leverages AI to manipulate data returned by APIs using a natural language interface that reduces the level of technical acumen required to create those workflows.

    That approach provides developers with a reactive experience that is embedded within a visual tool, noted Bhattacharya.

    Many developers still have a natural bias toward writing code, but as demand for applications continues to increase, Postman Flows provides a means to significantly increase developer productivity, said Bhattacharya. There may still be instances where writing code is required, but as developers save more time using Postman Flows, many of them will switch over to a visual tool to build software faster by essentially gluing blocks together, he added.

    There’s naturally a lot of focus these days on developer productivity during uncertain economic times. More organizations than ever are dependent on software, but their ability to hire armies of developers is limited. Low-code tools have emerged to provide a means for accelerating application development, but Postman is now looking to apply that concept directly to the network of curated APIs that it provides to application developers.

    The one thing that is certain is that as the pace at which applications are being built increases, the number of them running in production environments will steadily increase. DevOps teams will find themselves maintaining a wide range of applications that were constructed using both procedural code and low-code platforms.

    In the meantime, IT organizations may want to start evaluating which types of applications lend themselves to being built by development teams that may not require as much experience writing actual code. Much of the application development backlog organizations are struggling with today could be reduced using tools that automate a wide range of development tasks. That should free up developers with more advanced skills to work on more complex applications. That approach might also reduce developer turnover as much of the fatigue associated with building more routine applications is reduced.

    Regardless of how applications are built, there will be a need to manage them in production environments. DevOps teams may soon be able to focus more of their time and expertise on optimizing application performance in production environments versus continuing to shepherd massive amounts of code through continuous integration/continuous delivery (CI/CD) pipelines.

  • 5 Unusual Ways to Improve Code Quality

    5 Unusual Ways to Improve Code Quality

    Code quality refers to how well-written and maintainable software code is. It encompasses factors such as readability, efficiency, scalability, reliability, maintainability and security. High code quality ensures that software is easy to understand, modify and extend, has fewer bugs and is less likely to break down. It also reduces development time and costs and improves the overall user experience. One common approach to determine code quality is to use automated tools that analyze the code based on predefined quality standards and generate a report with a numerical score.

    Why is Code Quality Important?

    Generating high-quality code ultimately enhances the end user’s experience. Focusing on creating quality code can also help consumers understand the safety and reliability of the software or program they’re using.

    Low-quality code can affect user experience and satisfaction, making it critical to write high-quality code that functions properly. When developers write low-quality code, it can create vulnerabilities that expose the software to cybersecurity threats, resulting in bugs and functionality issues and impacting the software’s reliability. 

    Here are some additional reasons high-quality code is important: 

    • Enhances code readability: Readability is important because it leads to higher rates of understanding among other developers. A code that’s easy to read is also easy to improve.
    • Improves the level of program sustainability: Program sustainability measures how long a code can survive with minimal changes. High-quality code can last for years, making it more sustainable.
    • Increases transferability: Transferring code from one platform to another is a complicated process. It’s much easier for developers to transfer high-quality code, as they only need to make minimal changes.
    • Lowers costs related to program or software: When software lasts for a long time with few errors, it can save a company money. Instead of paying for additional time to rewrite low-quality code, the company can rely on the original, high-quality source code.

    5 Unusual Ways to Improve Code Quality

    Here are a few ways you may not have thought of which can help your development team improve code quality and end-user satisfaction.

    Bug Bounty

    A bug bounty program is a type of crowdsourced security testing in which an organization offers rewards to independent security researchers or ethical hackers for identifying and reporting vulnerabilities in their software or systems. By offering rewards for vulnerabilities, organizations can incentivize security researchers to find and report security issues before they can be exploited by attackers.

    Bug bounty programs can improve code quality in several ways:

    • Incentivize security testing: Bug bounty programs incentivize security researchers to test an organization’s software or systems for vulnerabilities. This can increase the amount and quality of security testing that is done, leading to a more secure product.
    • Encourage responsible disclosure: Bug bounty programs encourage security researchers to report vulnerabilities directly to the organization rather than publishing them publicly or selling them on the black market. This allows organizations to fix vulnerabilities before they are exploited by attackers.
    • Provide feedback on code quality: Security researchers who participate in bug bounty programs can provide feedback on code quality which can help organizations to improve their development practices and write more secure code in the future.

    Auto-Generated Documentation

    Auto-generated documentation is a type of documentation that is generated from code comments and metadata as part of an automated development pipeline. It is typically generated using tools such as Javadoc, Doxygen, or Sphinx, which parse code comments and metadata to generate HTML, PDF, or other formats of documentation.

    Auto-generated documentation can improve code quality in several ways:

    • Improved code readability: Auto-generated documentation can provide clear and concise descriptions of code functionality, making it easier for developers to understand the code and its purpose.
    • Better code organization: Auto-generated documentation can help developers organize their code by providing a clear hierarchy of classes, methods, and functions, making it easier to navigate and maintain the codebase.
    • Consistency: Auto-generated documentation can ensure that documentation is consistent across the codebase, reducing the risk of errors and misunderstandings.
    • Quality assurance: Auto-generated documentation can be used as a quality assurance tool, helping developers to identify errors and omissions in their code comments and metadata.

    Coding Conventions

    Coding conventions are a set of guidelines and standards that outline how code should be written and formatted to promote consistency and readability. They typically cover aspects such as naming conventions, code structure, formatting, and documentation. 

    By following coding conventions, developers can improve code quality and make their code easier to read and understand, which makes it easier to maintain and modify. They also help ensure that code is consistent across a project or organization, which can make collaboration and integration of different code segments easier.

    Typical elements that coding conventions dictate include:

    • Naming conventions for variables, functions, and classes.
    • Indentation and formatting of code blocks.
    • Use of whitespace and comments to improve readability.
    • Guidelines for handling exceptions, errors, and input/output.

    Quality Gates

    Quality gates are a set of checkpoints or criteria that software must meet before it can progress to the next stage of development. They are typically used in software development processes to ensure that the software is of a certain quality and is ready for release.

    Quality gates can be automated or manual, and they are typically implemented at key points in the development process, such as after unit testing, integration testing, or acceptance testing. They can include metrics such as code coverage, code quality, functionality, performance and security.

    By enforcing quality gates, development teams can catch and address issues earlier in the development process, which can reduce rework, save time and ensure that the final software product meets the required quality standards.

    Smart Code Snippets

    Smart code snippets, also known as intelligent code snippets or live templates, are pre-written code fragments that can be inserted into a code file with placeholders for variables or user-defined inputs. They are designed to help developers write code more efficiently and accurately by reducing the amount of repetitive or boilerplate code they need to write and by providing contextual awareness and intelligence.

    Regular code snippets are static pieces of code that can be inserted into a file as needed. They typically contain pre-written code blocks or templates that can be customized to fit the specific use case.

    In contrast, smart code snippets are dynamic and can adapt to the context of the code being written. For example, a smart code snippet might include placeholders for variables that need to be defined or automatically fill in common code constructs based on the context of the code. 

    Conclusion

    The five lesser-known ways to improve code quality discussed in this article offer a starting point for teams looking to take a fresh perspective on their development process. Improving code quality is critical for the success of any software development project. While there are many established methods and best practices for improving code quality, there are also some less conventional approaches that can be surprisingly effective. By adopting a creative and open-minded approach to software development, teams can identify new ways to improve code quality and build more reliable, efficient and secure software.

    Image Source 

  • DevOps Adoption in Salesforce Environments is Advancing

    DevOps Adoption in Salesforce Environments is Advancing

    A global survey of DevOps professionals building apps in Salesforce environments found 44% of respondents reported their organization has a continuous integration/continuous delivery (CI/CD) platform in place, with another 39% planning to adopt one.

    The survey, conducted by Gearset, a provider of a DevOps platform for building custom applications in Salesforce environments, polled 1,254 DevOps professionals that are building and deploying custom applications on top of the Salesforce software-as-a-service (SaaS) platform. The survey also found nearly half (49%) implemented change monitoring, with another 33% planning to follow suit. More than half (52%) implemented source-drive workflows, with another 33% similarly planning to follow suit. A total of 41% of respondents noted that, over the last 12 months, they have more custom code to manage.

    Overall, the survey found 54% of respondents reported increased productivity, followed by improved quality and faster releases at 41% each. Nearly three-quarters (72%) reported they are able to deploy changes from one environment to another within four hours. Well over a third (39%) of this group are able to complete a deployment in less than an hour. Just under a quarter (23%) are also able to release code multiple times a week.

    However, only 18% can release a new feature to production in less than a day. Nearly half can complete the release within one day to a week. A total of 43% claimed that less than 10% of releases include a bug or error, with 46% reporting they can roll back a release in a day or less, if needed. Just over a third can restore a process in a day or less.

    The biggest obstacle to DevOps adoption is lack of experience (41%), followed by a third (29%) of respondents that reported difficulties with collaboration and another 29% that experienced limited buy-in from the rest of the application development team. Only 30% received DevOps training once a month, with 50% citing additional CI/CD and automation training as their biggest need.

    Despite these issues, a full 98% are generating a return on their DevOps investments, with 59% of teams reporting returns of over $10,000 per month and 40% reporting returns in excess of $50,000 per month. The top two priorities for the next 12 months are to consolidate systems and processes and improve flexibility, tied at 47% each, followed closely by 43% that noted that digital business transformation is a top priority.

    David Runciman, technical content manager for Gearset, said that while Salesforce applications are based on unique object architecture, it’s apparent that organizations are extending those applications using, for example, low-code tools more quickly. The issue that creates is, as organizations move to deploy these applications, they are encountering bottlenecks that conspire to slow the pace of innovation, he noted.

    The maturity level of DevOps teams building these applications will naturally vary. However, as the number of applications being built—especially by professional developers—increases, it’s only a matter of time before more organizations embrace DevOps best practices to bring order to the chaos, noted Runciman. While there may be some citizen developers building applications in Salesforce environments, the bulk of enterprise-class applications are built by professional developers that typically appreciate DevOps best practices, he added.

    The issue remaining is just how quickly those DevOps teams will be able to implement DevOps best practices as demand for additional applications grows.

  • How Bazel and GitHub Can Fix the Dependency Availability Problem

    How Bazel and GitHub Can Fix the Dependency Availability Problem

    Recently, GitHub upgraded the internal version of Git they use to produce repository archives. You’ve probably used these archives before if you’ve downloaded a .zip or .tar.gz file from a repository at a particular version. GitHub produces those archives on demand using Git archive and caches them for a short time.

    Upgrading Git regularly is a generally good idea, but this change regrettably broke a huge number of Bazel projects. Bazel is a widely used, free, open source tool for building and testing software, so this breaking change is a big deal. What happened? Most Bazel projects fetch at least some of their dependencies using rules in their WORKSPACE files like this:

    http_archive(

    name = “com_github_bazelbuild_buildtools”, sha256 =

    “05eff86c1d444dde18d55ac890f766bce5e4db56c180ee86b5aacd6704a5feb9”, strip_prefix = “buildtools-6.0.0”,

    urls =

    [“https://github.com/bazelbuild/buildtools/archive/refs/tags/6.0.0.ta

    r.gz”],

    )

    See that /archive/refs/tags/ part of the path? That’s the endpoint I’m talking about.

    This is bare-bones dependency management: Bazel attempts to download an archive from the first URL in the list; it tries the next URL if the first is not available and so on. Bazel then checks the file’s SHA-256 sum against the known value and, if it’s correct, extracts the archive and proceeds with the build.

    The Git upgrade caused a change in archives’ SHA-256 sums. I think there was a small change in zip compression, but it doesn’t really matter—any variation in file ordering, alignment or compression causes the archives’ SHA-256 sums to change even though the extracted contents are the same.

    This is at least the third time Bazel builds have broken that I can remember. This has also been discussed extensively before. I’m writing this in the hope that we can make our systems more resilient and avoid these kinds of problems in the future.

    Since GitHub made the change that triggered this, they naturally get the immediate blame from the community, though I think it’s mostly undeserved. Upgrading dependencies (especially Git and especially if you’re GitHub) is a reasonable thing to do. To my knowledge, GitHub has not documented a guarantee that files returned by the archive endpoints have stable SHA-256 sums. It’s a mistake for users to rely on a guarantee that was never made. It’s tempting, of course, because it’s easy, but it’s a mistake nonetheless.

    This is a classic example of Hyrum’s Law:

    “With a sufficient number of users of an API, it does not matter what you promise in the contract: All observable behaviors of your system will be depended on by somebody.”

    Since these updates have broken Bazel (and presumably others) a few times now, I’d really like to see GitHub clarify in documentation whether users should or should not depend on stable archive SHA-256 sums. A GitHub engineer commented that this is not stable, but product managers and support engineers have commented at other times that is stable. I don’t really think discussion comments count since they’re not discoverable. Only official documentation is authoritative.

    I haven’t actually found any documentation for these release archive URLs, so I’m not sure where this clarification should go. It’s not part of the REST API. Linking to releases is pretty close.

    If archive SHA-256 sums are guaranteed to be stable (now or in the future), I think documenting and testing that would let us all sleep easier at night.

    If archive SHA-256 sums are not guaranteed to be stable, it wouldn’t be a terrible idea to inject a little chaos to prevent people from depending on them. For example, in Go, the iteration order of elements in a map is undefined. To prevent developers from depending on iteration order (and tests from breaking when the hashing algorithm is tweaked), the Go runtime adds a random factor into the hashing algorithm, so the iteration order is different every time a program runs. Something similar could be done here with archive file order or alignment. I wouldn’t suggest gratuitously breaking this API, but if it needs to change anyway for some reason in the future, it would be a good idea to add something like this.

    What Could the Bazel Community do Better?

    Bazel developers should not rely on stable archive SHA-256 sums unless that stability is guaranteed and documented by GitHub. More importantly, developers should not rely on dependency artifacts being available on GitHub at all: A library author could delete their project at any time.

    I’ll point to Go modules as a model of a great dependency management system designed to solve this exact problem. The Go team operates proxy.golang.org, a mirror for all publicly available Go modules. Internally, the proxy stores actual files for each module and does not need to regenerate them. The proxy protocol is open and easy to implement as an HTTP file server, so you can run your own proxy service for better availability. I’d love to see something like this happen for Bazel, especially if it’s operated by Google. It is not technically difficult to build a service like this, but there are a lot of thorny issues around handling abuse and legally distributing software with unrecognized licenses, and Google has already figured out those issues for Go.

    Until such a service exists, developers can protect themselves by copying their dependencies to their own mirror. A GCS or S3 bucket works fine.

    Library authors can and should protect their users by providing static release artifacts (not dynamically generated archives), and mirroring those. For example, check out the http_archive boilerplate for rules_go:

    http_archive(

    name = “io_bazel_rules_go”,

    sha256 =

    “dd926a88a564a9246713a9c00b35315f54cbd46b31a26d5d8fb264c07045f05d”, urls = [

    “https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/d ownload/v0.38.1/rules_go-v0.38.1.zip”,

    “https://github.com/bazelbuild/rules_go/releases/download/v0.38.1/rul es_go-v0.38.1.zip”,

    ],

    )

    The file rules_go-v0.38.1.zip is created by the rule authors and attached to the release; it’s not dynamically generated.

    It’s also copied to mirror.bazel.build, which is a thin frontend on a GCS bucket shared by many rule authors in the Bazelbuild organization.

    One other tip: If you’re feeling adventurous enough to use an experimental, undocumented feature (to make your build more stable! Really!), you can configure Bazel’s downloader to rewrite those GitHub URLs to point to your own mirror.

    Aside: SHA-256 of archives or contents?

    It’s unfortunate that a change to the Git archive that does not affect extracted contents of an archive can still change its SHA-256 sum. Bazel absolutely does the right thing by checking the sum of the downloaded file before extracting its contents.

    This is the (delightfully named) Cryptographic Doom Principle. If Bazel only authenticated the contents of an archive, it might be possible for an attacker to exploit a vulnerability in Bazel’s zip parser before the archive is authenticated. Since Bazel authenticates the archive before extracting it, the pre-authentication attack surface is very small.

    Closing Thoughts

    When you’re designing software, think carefully about how it’s going to be used. If there’s a right way and a wrong way to do something, make sure the right way is easier and more obvious. Better yet, make the right way the only way.

    I think this is a case where Bazel’s dependency management is too limited: To use http_archive safely, you need to set up an HTTP mirror with copies of your dependencies. That’s too much work for users, especially new users who aren’t aware of the hazards. A more complete dependency management system should include an artifact registry or a read-through caching system with at least one public implementation. I was hoping Bazel modules and the Bazel central registry would provide that, but the central registry only includes module metadata: Module content is separate, specified in URLs that still frequently refer to the unstable GitHub endpoint.

  • JFrog Aligns With New Relic to Improve Observability

    JFrog Aligns With New Relic to Improve Observability

    JFrog and New Relic jointly announced today they will provide a free integration tool that will enable New Relic’s observability platform to consume log data from JFrog platforms for building and deploying applications securely.

    Announced at the Futurestack conference hosted by New Relic, this integration eliminates the manual effort that was previously required to integrate these platforms. Preconfigured New Relic dashboards provide a comprehensive view of performance data, artifact usage and security metrics in real-time that is automatically collected from JFrog Artifactory and JFrog Xray environments and then displayed alongside other telemetry data.

    Omer Cohen, executive vice president of strategy at JFrog, said that capability will make it easier to identify performance issues, urgent vulnerabilities and malicious users in a way that reduces the amount of time required to remediate those issues across the software supply chain.

    The goal now is to eventually provide similar levels of integration between JFrog platforms that enable DevOps teams to manage and secure application binaries with other observability platforms, added Cohen.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on need to be augmented. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue. The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. The biggest challenge is understanding which queries to actually launch to identify an issue that might later cause a major disruption. In the longer term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify those issues. In the meantime, much still depends on the acumen of the DevOps team employing an observability platform.

    In fact, a recent New Relic survey found only 27% of respondents have achieved full-stack observability, with only 5% claiming they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found. More than half (52%) of respondents also admitted they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    On the plus side, nearly three-quarters (72%) expected to maintain or increase their observability budgets next year. More than half (52%) of respondents, including 57% of C-suite executives, expected observability budgets to increase over the next year. A total of 14% of all respondents and 16% of IT decision-makers expected to increase observability budgets significantly or extensively. More than a third (36%) believe observability increases their productivity and enables them to find and resolve issues faster. Just under a third (32%) said observability enables cross-team collaboration, while more than a quarter said observability improves their ability to innovate.

    One way or another, visibility into DevOps environments clearly needs to improve as application environments become more complex. The challenge, as always, is determining the cost required to achieve it.

  • Eclipse Foundation Touts Java SE Temurin Certification Momentum

    Eclipse Foundation Touts Java SE Temurin Certification Momentum

    The Eclipse Foundation revealed today the number of downloads for Java Standard Edition (SE)—dubbed Eclipse Temurin—certified using both a technology compatibility kit (TCK) and compatibility tests for evaluating associated runtimes reached 12.3 million in February.

    Tim Ellison, a project lead for creating compatibility tests for the Eclipse Foundation, said that level of activity suggests the governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based OpenJDK source code from multiple providers is gaining traction. Members of the Adoptium working group include Alibaba Cloud, Bloomberg, Google Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, Red Hat and Rivos. Eclipse Temurin has also become the default Java option for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    OpenJDK is a free and open source implementation of Java SE provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that allows it to run compatibility tests to ensure conformance to the Java specification.

    One of the reasons Eclipse Temurin is gaining traction is organizations are looking to reduce Java licensing costs during uncertain economic times by relying on an open source platform. At the same time, a consistent set of certified runtimes also reduces the level of DevOps friction that might otherwise be encountered when building and deploying Java applications, noted Ellison. There will, of course, always be multiple Java runtimes, but the level of incompatibility that would exist without testing them could be substantially higher, he noted.

    Despite the plethora of programming languages developers use, after more than 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Developers may be building and deploying applications faster, but most of them will continue to rely on the programming language they already know rather than master another. In addition, many of the Java applications that have been deployed over the last two decades are now being modernized within the context of a cloud migration.

    Arguably, Java is experiencing a renaissance following efforts to make it simpler for multiple organizations to contribute code to open source projects and increase the pace of innovation. The rate at which organizations can absorb that innovation will naturally vary, but it’s clear that more organizations are now running later editions of Java that improve both performance and cybersecurity overall.

    In the meantime, DevOps teams should expect to see more Java projects moving through pipelines in the months and years ahead. While not every legacy Java application may need to be updated before being retired, it’s apparent that the bulk of Java applications are still relevant. As such, it’s probable the efforts to modernize those applications will keep DevOps teams occupied well through the end of the decade.

  • SVB: When Silly Valley Sneezes, DevOps Catches a Cold

    SVB: When Silly Valley Sneezes, DevOps Catches a Cold

    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: Silicon Valley Bank and what it means for DevOps. After the débâcle of Wednesday’s fire sale, Thursday’s bank run and Friday’s FDIC seizure, came Saturday’s impotent panic, Sunday’s “not a bailout” federal guarantee and Monday’s tentative restart of “bridge” bank operation. (more…)

  • ReversingLabs Adds Ability to Detect Secrets in Application Binaries

    ReversingLabs Adds Ability to Detect Secrets in Application Binaries

    ReversingLabs today announced it added an ability to detect secrets exposed in application binaries to its Software Supply Chain Security (SSCS) platform.

    Tomislav Peričin, chief software architect for ReversingLabs, said this addition will make it easier for DevSecOps teams to identify secrets that are inadvertently left in applications as plain text or that can be discovered because of weak cryptography, scripts that have been included in directories that have secrets configuration files, packaging automation mistakes, compromised developer accounts or the activities of malicious insiders.

    The SSCS platform can identify more than 250 secret types out of the box, including private keys, version control, certs, tokens and more. Once they are identified, the platform also surfaces their precise location, which services are affected and if those secrets are exposed or leaked elsewhere. The platform also identifies third-party, open source, testing keys and other commonly shared secrets in addition to which secrets have already been exposed. Armed with those insights, it then becomes possible to better prioritize remediation efforts on actionable issues to reduce overall manual triage fatigue, noted Peričin.

    ReversingLabs also provides guidance for sensitive information policies, including documentation of public exposures and breakdowns of secrets used for web service access credentials, web service access tokens, web service API keys and webhook service access keys.

    Most software composition analysis (SCA) tools used to secure software supply chains are limited to identifying issues in source code. As applications become more modular, however, the odds authentication credentials such as login credentials, application programming interface (API) tokens and encryption keys might be left exposed because of a developer mistake substantially increase. The overall goal is to make it possible for DevSecOps teams to discover these issues in binary code before an application is deployed, noted Peričin. That “just in time” approach to secrets management includes canary token management and custom detection policies to better ensure application security.

    In general, secrets within applications are becoming more challenging to secure as cybercriminals increasingly scan repositories and continuous integration/continuous delivery (CI/CD) platforms to find them. The ultimate goal is to inject malware into a software component that will be used in multiple downstream applications. Once activated, that malware will then create a backdoor through which cybercriminals can exfiltrate data or launch a full-blown ransomware attack. It was the latter type of attack that led to the U.S. government creating a formal National Cybersecurity Strategy to, in part, lock down the software supply chains employed by federal agencies to build applications.

    A recent survey published by ReversingLabs, however, found that while 87% of respondents agreed that software tampering has become a more frequently used cybersecurity attack, only 37% said they have any means to detect it. Only 7% said they could detect software tampering at each phase of the software development life cycle.

    It’s not clear to what degree best DevSecOps practices are currently being implemented within application development teams, but as more attacks are launched against software supply chains, it’s now only a matter of time before most DevOps teams are routinely required to scan code for exposed secrets and known vulnerabilities long before code is allowed anywhere near a production environment.