Tag: runtime

  • Introduction to SPIFFE/SPIRE

    Introduction to SPIFFE/SPIRE

    For a long time, people have been logging into the apps they use via passwords or password managers. And many open standards and identity providers on the market continue to evolve how users authenticate and authorize with websites and applications. The issue is that the same problem exists for software services—when applications talk to applications, how do we prove the credibility of service-to-service connections?

    Enter SPIFFE and SPIRE. SPIFFE is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. Together, the projects create a standardized, secure way to identify software services and authenticate them. SPIFFE and SPIRE recently reached graduation status with the Cloud Native Computing Foundation (CNCF), solidifying the projects’ maturity as a top open-source standard mechanism to deliver cryptographic runtime identity for both cloud-native and legacy workloads.

    SPIFFE and SPIRE are already used across many major public deployments. Yet not all developers are familiar with their intricacies. Below, I’ll take a gander at both projects and how they operate to provide a bit more context. I also spoke with Evan Gilman, SPIFFE/SPIRE maintainer, to gather more insights on the history of the projects and their future goalposts.

    What is SPIFFE?

    The Secure Production Identity Framework For Everyone (SPIFFE) is a specification for workload identity. According to Gilman, the easiest way to think about SPIFFE is as a passport. Similar to how people are issued passports in a common shape with a barcode and standard information, SPIFFE dictates the standard methods to prove and validate the identity of a service. It’s like bringing the “Sign in with Google” experience to the software services themselves, he adds.

    There are three key components in SPIFFE. First, SPIFFE specifies that services shall identify themselves with what’s called a SPIFFE ID, which is defined as a URI in the format of spiffe://trust-domain-name/path. These IDs are then encoded into a SPIFFE Verifiable Identity Document or SVID. SVIDs aren’t so much a document type themselves — instead, they support either X.509 or JWT document types. Last but not least, SPIFFE specifies a workload API that issues and rotates these SVIDs, along with the keys needed to validate them.

    What is SPIRE?

    SPIRE is the code that implements the SPIFFE specification—you can think of it as a production-ready SPIFFE runtime environment. SPIRE, the “flagship SPIFFE implementation,” is a true end-to-end instantiation of SPIFFE that securely issues SVIDs, renews SVIDS and performs attestation, among other functions. If SPIFFE defines what a passport is, then SPIRE is the agency that issues the passports, said Gilman.

    The SPIRE agent runs on a node and exposes the workload API, which hooks into each workload. A workload, as defined by the SPIFFE documentation can be a web server, an instance of a MySQL database, a worker program or a web application composed of independently deployed systems. By communicating in this manner, SPIFFE/SPIRE can solve the issue of “secret zero,” which refers to the conundrum of proving the first credential to newfound systems.

    More Background on SPIFFE/SPIRE

    Joe Beda, a co-founder of Kubernetes, first proposed SPIFFE at GlueCon in 2016. At the time, Google was considering what internal technology it had that might prove helpful to the broader industry. It’s said that the technology that inspired SPIFFE/SPIRE can trace its roots to security and identity subsystems brought to Google from AT&T and Bell Labs.

    Nowadays, SPIFFE/SPIRE is actively maintained by many organizations, and we continue to see impressive production use cases. “SPIRE is deployed in some staggeringly large cases,” explained Gilman. SPIFFE/SPIRE adoption can be seen within GitHub, Netflix, Pinterest, Square, Transferwise, Uber and many other large technology companies. In terms of ownership, Gilman said that SPIRE is most used by platform engineers, infrastructure engineers or security engineers, depending on the organization’s roles.

    Future Outlook for SPIFFE and SPIRE

    SPIFFE/SPIRE appear to have the resources and backing to maintain a stable implementation, so the future looks bright for both projects. In terms of new features, in mid-2022, a first-class integration with SPIRE was merged into the Istio service mesh as a more flexible alternative to Istio’s built-in SPIFFE implementation. Another recent update is experimental support for SPIRE on Windows. Regarding future plans, SPIFFE/SPIRE maintainers will likely continue to iteratively improve the specification and implementation with frequent updates.

  • Dynatrace Extends Reach of Application Security Module

    Dynatrace Extends Reach of Application Security Module

    Dynatrace has extended the Application Security Module it provides for its observability platform to protect against vulnerabilities in runtime environments, including the Java Virtual Machine (JVM), Node.js runtime and .NET CLR.

    In addition, Dynatrace has extended its support to applications built using the Go programming language.

    The Dynatrace Application Security Module leverages existing Dynatrace tracing and artificial intelligence (AI) technologies to detect threats in real-time and then apply appropriate policies to automatically secure applications. At the core of the Dynatrace approach to application security is its OneAgent software for application instrumentation, which collects data and feeds it back to an observability platform that includes an AI engine dubbed Davis.

    Amit Shah, director of product marketing for application security at Dynatrace, said by extending the Application Security Module to support runtimes in the most widely adopted programming languages Dynatrace is now providing real-time visibility and vulnerability analytics across the entire application stack, which includes custom code, open-source and third-party libraries, language runtimes, container runtimes, and container orchestrators.

    The Dynatrace platform not only identifies vulnerabilities across each of these layers automatically but also analyzes them to reduce false positives by only surfacing alerts concerning code that is actually running, noted Shah. Without those capabilities, it becomes impossible for development teams to prioritize their application remediation efforts in the absence of any context, he added.

    In general, achieving and maintaining application security will require more responsibility to shift both left and right, said Shah. While it’s critical to discover as many vulnerabilities as possible before applications are deployed it’s also crucial to make it simpler to discover vulnerabilities in runtimes after an application is deployed, he noted. The goal is to enable DevOps teams to employ the same observability platform they are using to manage and optimize applications to also ensure application security, Shah added.

    That Dynatrace approach provides the added benefit of also avoiding the need to convene a “war room” to discover where all the vulnerabilities in those application environments might reside once they are discovered, Shah noted.

    The primary application security challenge organizations face is the rate at which applications are now being deployed. Cybersecurity teams, because of a chronic shortage of talent and expertise, can’t keep pace. As a result, more responsibility for application security is being shifted left toward developers and DevOps teams as well as right toward IT and security operations teams. In effect, application security is finally becoming a team sport within IT organization as cybersecurity teams focus more of their efforts on securing runtime environments, noted Shah.

    It may be a while before that approach has a major impact in terms of reducing the number of vulnerabilities being regularly introduced into application environments. However, as more tools and platforms that specifically address application security are deployed, the overall state of application security will steadily improve.

    In the meantime, however, the volume of attacks aimed at the application layer of the IT stack will, unfortunately, continue to increase as cybercriminals focus more of their efforts on exploiting both now and zero-day application vulnerabilities that are increasing in volume with each passing day.

  • CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic Toolkit Increases Visibility Into App Dependencies

    CodeLogic launched today a toolkit that enables developers to scan binaries, runtime application behavior and database connections and then leverage graph technology to identify connections and dependencies in real-time.

    Brian Pierce, CodeLogic CEO, said the goal is to make it simpler for developers to identify the relationship between application elements to increase overall productivity and simplify the addition of new members to an application development project.

    In general, most developers add code to applications without really having much visibility into how that code might impact other components. The toolkit created by CodeLogic is an extension of the company’s existing continuous software intelligence (CSI) platform that employs server software to store and process data collected via its agent software. The goal is to make it easier for developers to directly consume those insights via a toolkit they can access directly from within, for example, an integrated development environment (IDE), said Pierce.

    As applications become more complex in the age of microservices, it becomes more challenging to understand all the dependencies between application components. Developers require greater visibility into applications to better manage the break/fix process that inevitably occurs when new code is added to any environment. The CodeLogic CSI platform provides an automated impact score for methods, classes and the overall health of an application as code is developed to provide that visibility.

    That information also plays a critical role in enabling IT teams to understand the implications any newly discovered vulnerability might have on the application environment, added Pierce.

    Overall, the level of technical debt that organizations accumulate over time saps developer productivity, he noted. The more difficult it becomes to add code to an application environment the less likely it is that developers will enthusiastically make the effort, said Pierce. Before too long, the number of updates made to an application environment starts to decline, he noted.

    Developer productivity has become a major issue simply because the number of applications that organizations now want to build and deploy is exceeding the financial resources they have available to hire or contract developers. The more time developers spend studying how an application has been constructed the less time there is to write code and drive innovation. In fact, the more frustrating it becomes to add code the more likely it becomes developers will move on to a company with much less friction involved in building and deploying applications, said Pierce.

    There are many senior IT leaders that also need visibility into application environments before approving projects. Many IT teams discover that there are multiple projects or other teams writing duplicate code or replicating existing functions. Regardless of the reason, more developers are voting with their feet when they feel their time and effort is not fully appreciated.

  • Cloud Foundry Study Confirms Accelerated App Development

    Cloud Foundry Study Confirms Accelerated App Development

    When it comes to accelerating the development of applications, having a standard set of runtimes can make all the difference. A new study of 753 IT professionals conducted by ClearPath Strategies on behalf of the Cloud Foundry Foundation (CFF) finds a marked decrease in the time it takes organizations using the Cloud Foundry platform-as-a-service (PaaS) environment to develop code—just 18 percent need three months or longer, compared with 51 percent of respondents that don’t use the Cloud Foundry Application Runtime. And, according to the study, the 46 percent of responding companies that use the Cloud Foundry Application Runtime see application development times of less than a week, compared with only 16 percent of non-users.

    Abby Kearns, executive director for CFF, says use of Cloud Foundry Application Runtime has expanded considerably in the last year. Nearly half (45 percent) of the respondent have been using the PaaS environment in the last year. The survey also finds that more than half (51 percent) now have more than 10 developers employing Cloud Foundry Application Runtime, while 28 percent now have more than 50 developers.

    Kearns says those results are noteworthy because it shows that CF is now being used for a lot more than simple proof-of-concept projects. In fact, Kearns notes use of CF to develop a broader range of cloud-native application is increasing. The study finds half of Cloud Foundry users currently use containers, with another 35 percent evaluating or deploying containers.

    Kearns says there’s a high correlation between implementations of CF and adoption of DevOps processes. He notes that often organizations decide to implement CF to force the DevOps issue—a PaaS environment the size and scale of CF requires every process and function within an IT environment to participate in what has become a large-scale continuous application/continuous integration (CI/CD) platform operating at scale. Confronted with that requirement, Kearns says it’s not too long before the IT culture adjusts to that new reality by implementing a new organizational structure.

    CF is not the only PaaS game in town. But via CF distributions from Pivotal, IBM, SAP and others, use of CF has steadily grown, especially among larger enterprises that have the skills required to implement CF at scale. The survey finds that enterprise IT organizations with more than $1 billion in revenue account about half (49 percent) of all CF users. As deployments of the various elements of a PaaS environment becomes more automated, adoption of CF in small-to-medium enterprises should increase.

    In the meantime, IT organizations need think through the amount of time and money developers are wasting using alternative approaches. Not every IT organization appreciates the opinionated workflows that are baked into a PaaS environment. But given the length of time it takes to build applications using other platforms—as well the total cost of maintaining those environments—building and deploying applications at a higher level of PaaS abstraction is difficult to ignore. In fact, managing IT at a higher level of abstraction may eventually prove to be the difference between thriving and merely surviving.

    — Mike Vizard