devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • 15 Ways Software Becomes a Cyberthreat

    15 Ways Software Becomes a Cyberthreat

    Software is an integral part of private and commercial life; there is no way around it. You need software to do your taxes, book a flight or browse the internet. Software has made our lives much easier in so many ways. However, as we become more reliant on software we also become more vulnerable to cyberattacks.

    This article will explore 15 different ways that software can end up becoming a cybersecurity threat. By understanding these risks, you can take steps to protect yourself and your business.

    Lack of Security Features

    Many popular software programs either lack basic security features or the features that are present lose functionality, leaving users vulnerable to attack. For example, Adobe Reader and Microsoft Word have both been found to have security vulnerabilities. If you use these programs, make sure you keep them up to date with the latest security patches.

    If you are worried about having to deal with downtime while installing new software updates, you can always schedule them for a time when you know you won’t be using your computer. This way, you can be sure that your software is always up-to-date and secure.

    Poor Password Security

    One of the most common ways users’ accounts get hacked is through the use of weak or easily guessed passwords. If you use a program that requires a password, make sure to use a strong one that would be difficult for someone to guess.

    Additionally, if you use the same password for multiple accounts, an attacker only needs to figure out that one password to gain access to all of your accounts. This is why it’s important to use different passwords for different services. If you can’t remember all of your different passwords, you can use a password manager to help you keep track of them.

    Consider using both a password manager—to take advantage of the more robust security these applications typically have—as well as a password randomizer, which will generate long, random passwords for you. Many password managers include a randomizer feature.

    Phishing Attacks

    Phishing attacks can impact any type of software program. In a phishing attack, an attacker will try to trick you into giving them your password or other sensitive information by masquerading as a legitimate website or program. Be very careful about any emails or messages you receive that ask for personal information, and never click on links in these messages unless you’re absolutely sure they’re legitimate.

    Phishing that takes place through software programs can also happen through messaging programs, like Skype or Facebook Messenger, or through email programs, like Gmail. Be sure to be cautious about any links or attachments you receive through these programs, as well.

    Keyloggers

    Keyloggers are malicious programs that are installed on your computer without your knowledge. Once they’re installed, they can track every keystroke you make, which means they can easily steal passwords and other sensitive information. Keyloggers can be installed through email attachments, malicious websites or even infected USB drives.

    To protect yourself from keyloggers, never install software from untrustworthy sources. Be very careful about what emails you open and what websites you visit. If you do get a keylogger on your computer, make sure to run a malware scan as soon as possible to remove it.

    Drive-by Downloads

    Drive-by downloads are another type of malicious software that can be installed on your computer without your knowledge. These types of programs are usually downloaded when you visit a malicious website or click on a malicious link. Once they’re installed, they can do things like steal your passwords or track your web browsing.

    To protect yourself from drive-by downloads, be careful about what websites you visit and what links you click on. If you think you may have downloaded a malicious program, run a malware scan as soon as possible.

    Malware

    Malware is malicious software that can infect your computer without you even knowing about it and, once it’s there, it can do things like steal your passwords or data or give an attacker remote access to your machine. From there, attackers can potentially access your organization’s IT infrastructure. Be very careful about what email attachments you open and what websites you visit, as these are two of the most common ways malware can end up on your computer.

    The software you use can also be used to introduce ransomware into your system. A malicious actor could create a fake version of a popular software program and distribute it online. When users download and install the fake software, they unknowingly grant the attacker access to their system. Or, an attacker could exploit vulnerabilities in software programs to gain access to a user’s system. Once inside, the attacker could install ransomware and encrypt the user’s files.

    Unsecured Wi-Fi Networks

    If you use public Wi-Fi networks to connect to the internet, you may be putting yourself and your organization at risk. These networks are often unsecured, which means that anyone else on the network can snoop on your traffic and see what you’re doing. If you need to use public Wi-Fi, make sure to connect to a secure VPN first so that your traffic is encrypted and private.

    Social Engineering

    Social engineering is a type of attack where an attacker tries to trick you into doing something that will give them access to your account or data. For example, they may pretend to be a customer support agent for a program you use and ask you for your password so they can “fix” an issue with your account.

    Or, they may send you an email that looks like it’s from a trusted source but actually contains a malicious link. Be very careful about any communications you receive, even if they appear to be from a legitimate source.

    Unsafe Browser Extensions

    If you use a web browser like Google Chrome or Mozilla Firefox, you may have installed some extensions to add additional features or functionality. But some of these extensions can actually introduce security risks. For example, an extension might have access to all of the websites you visit and the data you enter into them. Be very selective about which extensions you install, and only install ones from trusted sources.

    WordPress Plugins

    If you have a WordPress website, be careful about which plugins you install. Some plugins can introduce security risks, for example, by giving attackers access to your website or database. Install only trusted plugins, and make sure to keep them up-to-date. Also, while browsing new plugins, it is important that you ensure you are downloading and installing plugins that are regularly updated. Take a look at the last time the software was updated before deciding to install it.

    Adware

    Adware is a type of software that displays advertising on your computer, often in the form of pop-up ads. While not all adware is malicious, some forms of it can track your online activities and even collect sensitive information like your passwords or credit card numbers. Be careful about what programs you install, and always read the EULA before agreeing to anything.

    Google Docs

    Google Docs is a popular cloud-based word processing application that is part of Google Workspace. While it’s generally safe to use, there have been some reports of malicious actors using it to spread malware or launch phishing attacks. If you use Google Docs, be sure to only open documents from trusted sources and never click on any links in a document unless you’re absolutely sure they’re safe.

    Third-Party App Stores

    If you use an Android device, you may be tempted to download apps from a third-party app store instead of the official Google Play store. While there are some legitimate app stores out there, many of them are full of malware and other malicious programs. It’s always best to stick to the official app store for your device to avoid these risks.

    Outdated Software

    One of the most important things you can do to keep your computer safe is to make sure all of your software is updated to the latest version. Software developers regularly release updates that patch security vulnerabilities, so it’s important to install these updates as soon as they’re available. You can typically set your software to update automatically or you can check for updates manually on a regular basis.

    Commandeering For Loops

    Commandeering for loops is a type of attack where an attacker takes control of your computer by sending malicious commands through the command-line interface. This can happen if you accidentally download and run a malicious program or if you visit a website that has been compromised by an attacker. To protect yourself from this type of attack, be careful about the programs you download and run and only visit websites that you trust.

    Conclusion

    Software, in its myriad forms, is crucial to running both our businesses and enhancing our personal lives. There is almost no way to avoid using several, if not dozens, of different programs on a daily basis. But as we’ve seen, even the most innocuous-seeming software can pose a serious security risk if it’s not used properly. But understanding the attack vectors ahead of time can help protect yourself and your organization from these risks and keep your data safe.

  • Top 3 Requirements for Next-Gen ML Tools

    Top 3 Requirements for Next-Gen ML Tools

    As the machine learning market matures, new tools are evolving that better match data science and machine learning teams’ needs. Vendors, both open source and private, have been quick to introduce new products that better meet requirements making it easier and faster to develop models and enable collaboration.

    These new offerings range from cloud-based platforms that make it easy to build and deploy models to specialized software that can speed up the training process. As an example, the existing field of ML experiment tracking is a multi-billion dollar market with a crowded amount of vendors: Comet ML, Weights & Biases, Neptune AI, Databricks’ MLflow and more. These tools will need to evolve to move beyond meeting only the basic requirements of ML teams like experiment tracking, visualizations and model training to address collaboration and technical requirements so these teams can get models to market faster.

    The types of teams that are driving modern requirements for data science are the bet-the-farm types, where it’s all about finding new technology and solutions to drive efficiencies and get models to market faster for their organizations to maintain a competitive edge. Going forward, we’re seeing the following as requirements for ML teams as they evaluate tools to add to their MLOps stack.

     An Open, Modular Approach

    Data scientists and ML engineers use multiple tools to do their jobs, from Jupyter notebooks for model coding to DVC for experiment and data versioning, to automation tools like AirFlow to model visualization tools. Solutions will need to be open to integration with other tools instead of a walled garden that many ML tools, like those offered by cloud vendors (e.g. Amazon SageMaker, etc.) are now.

    Familiar Developer Experience

    ML developers and engineers are familiar with standard DevOps tools and workflows like GitOps (think GitHub or GitLab) and live in CLI-oriented solutions. ML tools should integrate tightly with these existing tools instead of complicating the developer experience with a separate ecosystem. And as a part of the developer experience, workflow is also important. Data scientists can run hundreds of experiments using their preferred CLI-based solutions but, often, all those experiments are streamed and posted into existing ML tools. A more optimal approach would be to offer data scientists the experience of running experiments locally and letting them commit only the most important experiments for further discussion and collaboration so the team isn’t overwhelmed.

    Strong Connection to Source Code

    This approach makes a stronger foundation for something like tracking ML experiments. As ML teams race to get models to market and continually improve them, being in lockstep with DevOps teams to deploy those ML models into production is critical. An example would be a developer tracking five experiments with changing hyperparameters. For these experiments, they may have a link to a Git repo for a particular version of source code. But what if the source code changes or data set changes are not committed or reported in their existing ML solution? Then, the connection is lost and existing metrics would be based on a previous version of source code or data that’s no longer accurate. That lost connection slows down time-to-market and makes it harder to optimize models.

    As seen with the above examples, ML teams juggle myriad tools and workflows as they develop models for various applications and services. The requirements discussed will help these teams to collaborate better and build models faster in an increasingly heterogeneous MLOps landscape.

  • How Waterfall Methodologies Stifle Enterprise Agility

    How Waterfall Methodologies Stifle Enterprise Agility

    In this age of sweeping digital transformation and accelerated change, organizations are recognizing that depending solely upon the drawn-out process of waterfall methodology is no longer sustainable if they are to remain competitive and relevant.

    Enterprise infrastructure must incrementally embrace evolution from monolithic architectures in response to the escalating pace of technological innovation, ever-changing consumer needs and demands and the failure of a long-running single project focus.

    EA Must Continuously Adapt 

    Traditional enterprise architecture (EA) frameworks struggle to manage the impact of disruptive technologies and systems that are agile and flexible. An architecture design approach that embraces continual evaluation and iteration is better equipped to navigate change and capitalize on emerging trends and innovations. Adaptability, in this context, may be defined as the fluid ability to modify, restructure and recreate the architecture in relation to changes within and external to the enterprise. It involves the early identification and rapid response to new product concepts, important trends, events and consumer demands; developing a “from the outside in” perspective.

    This adaptability, or ‘evolvability,’ quotient enables the flexibility and agility to deliver services and products reliably in this new development norm. Enterprise leaders are quickly acknowledging the need to inject a more open and agile format into their enterprise’s processes, at least in some measure, to succeed in today’s unpredictable environment.

    The Waterfall Model Constrains Enterprise Agility

    Traditional organizational architecture can impose limitations on an enterprise’s ability to successfully reach its digital transformation goals. The up-front model, with a focus on one long-range project, can slow productivity and choke creativity. While planning is needed as agility scales, the detailed technology life cycles with large timeline projections are no longer effective or profitable in meeting the business mandates that drive enterprises forward. Enterprise leaders are increasingly abandoning the five-year architectural plan for one that is designed to evolve with the ever-changing software development environment.

    Enterprise architects must now develop and promote adaptive methods that support agility in order to appropriate the value of new technologies like AI, machine learning, big data, IoT and intuitive tools that enable advanced analytics and enterprise-wide collaboration. A less intentional architecture, decomposed into smaller units, can be managed by autonomous cross-functional teams that are accountable to peers and managers with shared strategic objectives, bringing all fields into a coherent whole.

    A continuous architecture design with no end state, guided by iterative changes, will fluidly address the changing needs of the enterprise. A shift from a project-oriented to a product-oriented management mindset leads to faster learning cycles, shorter time-to-market, higher quality and increased revenues.

    The Attributes of a Flexible and Adaptive EA

    An open architecture designed to evolve in an ongoing manner and enable agility will include many beneficial characteristics and principles. Flexible and adaptive EA:

    • Provides product-centricity that connects software development to business goals;
    • Explores multiple solutions simultaneously with shorter analysis, testing, experimentation cycles and progression to eliminate weak solutions;
    • Empowers autonomous, cross-functional teams with clear accountability roles and alignment to a shared mission statement and effective information sharing;
    • Enables flexible and efficient resource allocation driven by changing demands or activity levels;
    • Strengthens an evolving roadmap that shows vision and targets, open to the whole enterprise, to allow input and questions for collaboration, cohesion and transparency;
    • Facilitates incremental changes to software architecture in a continuous manner;
    • Provides a continuous integration and delivery model with automatic testing for ‘good enough’ MVPs to keep the business moving forward.

    An adaptive EA allows for timely decision-making as agility scales, ensuring that the right products are delivered at the right time in alignment with business initiatives. When design accountability is distributed across the enterprise, consensus on complex decisions involving diverse stakeholders is more easily attained.

    The business rewards of transitioning to an adaptive architecture should be an easy sell by examining and tracking the monetary, time and customer success gains. The evolution toward adaptive enterprise architecture can reap numerable benefits. In addition to fostering an enterprise culture of continuous improvement, it accelerates and improves development cycles, journeys and outcomes for stakeholders and customers.

    Adaptive EA addresses the inherent uncertainties and complexities associated with dynamic business changes. It can deliver the rapid incremental changes, capabilities and benefits that a waterfall model inhibits. The agile and open methodology, empowered to continually evaluate and modify, provides visibility into project requirements and feasibility to reduce risks typically experienced with a traditional design and waterfall methodology.

    Making the Transition to an Agile EA

    Transforming enterprise architecture to a more adaptive and agile model will require planning and investment. A necessary first step is to assess what the enterprise goals and objectives are in making the transition. To what degree is the organization ready and what needs to be in place in order to move forward?

    Investing in an enterprise-wide training program of agile technologies, principles and methodologies will develop a cohesive and cooperative mindset that overcomes resistance to change and optimizes transition success.

    Of utmost importance is the development of a culture of communication, from the C-suite down across all stakeholders. A shared vision must be communicated and encouraged within a collaborative framework to cultivate enterprise-wide buy-in and acceptance of changes from waterfall methodologies to current roles and practices. In the migration to agile, there can be many obstacles, but by adopting an incremental approach with frequent reassessments an enterprise can ease the transition.

  • Does GraphQL Introduce New Security Risks?

    Does GraphQL Introduce New Security Risks?

    The GraphQL query language is an excellent tool for increasing the ease of data sharing. The premise is that you request the fields you need in a single bundled request, avoiding multiple network calls. Due to its usability, GraphQL is a growing area of development. Yet, as with any new technology, it comes with caveats.

    REST APIs function as a request-and-response paradigm in which the receiver accesses one resource at a time. On the other hand, GraphQL exposes many fields at once, requiring additional rate-limiting and time-outs to avoid nefarious queries. Additionally, the ability to traverse the entire schema could be abused by attackers to expose intricate data linkages. There are also some usability features with GraphQL that could be abused if misconfigured.

    GraphQL is a friendly alternative to REST. But how do we handle the security implications of GraphQL? I recently chatted with Mike Benjamin, vice president of security research, Fastly, to dive deeper into the security repercussions of adopting GraphQL. Below, we’ll consider the unique insecurities associated with GraphQL and suggest specific steps to limit the impact of these risks.

    Four GraphQL Security Vulnerabilities

    1. Introspection

    GraphQL provides built-in documentation that tells developers what the fields are, providing a schema of everything you can query. You’ve essentially given the entire dataset schema to a developer, meaning they can perform introspection to capture attack surface information. Hackers will most commonly look for injection or mutation capabilities that they can exploit, explained Benjamin. Or, they might seek to leverage the interlinkages between data to map a way through to classified information.

    To mitigate this problem, Benjamin cautioned against over-exposing all documentation publicly. Instead, he suggested using a restrictive security model for external viewers. “Provide appropriate user documentation in a different method,” he says. This may end up looking more like the standard REST API view of documentation.

    2. Field Suggestions

    Another usability benefit in GraphQL could also be a potential security concern—field suggestions. Field suggestions occur when you don’t enter the correct field name or enter a partial input and the system returns a hint. You might type in 0 or user, and the system makes a suggestion to fill out the rest of the field.

    This user interaction improves the developer experience, but, unfortunately, it could be abused by a hacker, said Benjamin. Thus, he recommended disabling hints after initial development. Or, if you decide to keep it in, he recommended placing a limit on its use. For example, if you try this more than five times in a second, the system could flag it as a bot.

    Right now, this attack vector is pretty limited, but Benjamin anticipated that, over time, hackers could automate this introspection with mass scanners to divulge more information.

    3. Denial-of-Service-Oriented Attacks

    Without the proper guardrails, all web APIs are prone to denial-of-service (DoS) attacks. Such an attack may pummel a service with a million queries per second to shut it off completely. In the case of GraphQL, these queries can dive very deep in a nested data relationship. A social network, for example, might expose friends of users, friends of users’ friends and so on.

    Or, hackers might utilize GraphQL’s bulk query ability to perform reconnaissance, brute-forcing the enumeration of data to query hundreds of user IDs to see which are valid. If you’re allowing unlimited data retrieval bundled within a single request, you could be inviting hundreds of bundled queries that could expose large swaths of the underlying database in one fell swoop.

    To counter these actions, Benjamin recommended limiting the testing depth. This could involve placing limits on how long a query can run, which would cause a time-out for requests that require suspiciously high degrees of processing. Another option is to limit how deep the bundling can get, said Benjamin. For example, perhaps the system restricts going three levels deep into a graph database, as that could expose millions of interconnected endpoints.

    4. Lack of Object-Level Authorization

    Another vulnerability that GraphQL endpoints may be prone to is a lack of object-level authorization, which hackers could leverage to get at a datapoint through its edges, said Benjamin. Since the idea is that you can access any data from one all-encompassing endpoint, authorization rules are often too abstracted away from the actual data. Queries may be able to access nested data or query relationships between data, too, which may unintentionally divulge information.

    Benjamin recommended placing authorization closer to your objects or data to rectify this issue. Use authorization-level controls that align permissions structure and roles with users. “Everyone needs a common authorization model,” said Benjamin.

    Future Evolution: GraphQL Security Matures

    As I’ve written before, the greatest strength of GraphQL is also its greatest weakness. Using GraphQL with default settings is a security trade-off in favor of usability. But according to Benjamin, we’re seeing more GraphQL servers disabling some introspection features, which he sees as a very positive move and a sign of maturity of the base configuration.

    GraphQL might suffer from similar threats that all APIs are vulnerable to, such as XSS, injection, DDoS attacks and broken authorization. However, Benjamin stressed that the added complexity of GraphQL makes it a unique case. “The most important thing for folks to consider is that GraphQL is more complicated than a REST endpoint—much more complicated,” said Benjamin. “GraphQL is unique in that it has linkages of data which contributes to complexity. It takes a little more time to think about how that’s confirmed, how it’s presented and how it would be attacked.”

    In other words, with great power comes great responsibility.

    Although exploits in public GraphQL APIs are still rare, we should stay vigilant. Benjamin encouraged developers to continue reading about, understanding and thinking about these attack vectors when designing their interfaces, as these risks will become more prominent as GraphQL usage grows and hackers become more familiar with these specific frailties.

  • OpenSSF Adds Open Source Package Analysis Tool Prototype

    OpenSSF Adds Open Source Package Analysis Tool Prototype

    The Open Source Security Foundation (OpenSSF) has made available a prototype of a package analysis tool that has already identified more than 200 malicious packages uploaded to PyPI and npm software components.

    Caleb Brown, an OpenSSF maintainer of the project, said the goal is to understand the behavior and capabilities of packages available on open source repositories. It also tracks how packages behave over time to make it easier to identify when previously safe software began to act in a suspicious manner.

    Most of the malicious packages detected are employing dependency confusion and typosquatting techniques, Brown said. They usually contain a simple script that runs during installation and provides a few details about the host to an external command-and-control system. Most of these packages are not exfiltrating meaningful data except the name of the machine or a username, but they make no attempt to disguise their behavior. The issue is that any one of these packages could have done far more damage, noted Brown.

    Future goals for the project include detecting differences in package behavior over time; automating the processing of the package analysis results; storing the packages themselves as they are processed for long-term analysis and improving the reliability of the pipeline. As such, the OpenSSF is looking for application developers and cybersecurity researchers to contribute to the project. The expectation is that many providers of application security tools will incorporate the package analysis tool within their offerings rather than requiring each vendor to create their own version of the same tool, said Brown.

    The OpenSSF has launched a series of initiatives to improve the overall state of open source security. Most recently, it added an Alpha-Omega Project to automate security testing processes for open source software using a $5 million initial investment provided by Microsoft and Google. The core challenge is that many organizations are dependent on open source software projects created and maintained by just a handful of volunteer maintainers and contributors. The individuals that created those projects don’t always have a lot of cybersecurity expertise. In fact, many of them would argue that the onus for securing open source software is on the organizations that use what amounts to free software. It’s not the responsibility of the contributors and maintainers to, for example, drop everything and immediately create a patch to address a zero-day vulnerability.

    It’s not clear how easily open source software could be compromised by cybercriminals that insert malware into downstream applications that rely on that code. However, in the wake of a series of high-profile breaches, it’s safe to assume that more cybercriminals than ever are trying to compromise open source software projects. While some organizations may opt to limit their dependency on open source code that has not been properly vetted, there is no way to entirely avoid using open source code. The challenge is finding a more efficient way to ensure the integrity of that code for all concerned.

  • Checkmarx Report Highlights Need for AppSec Collaboration

    Checkmarx Report Highlights Need for AppSec Collaboration

    A research report published by Checkmarx finds the same basic malicious software developed using multiple programming languages as cyberattackers industrialize their malware development processes.

    Checkmarx, a provider of code scanning tools, shared examples of malicious packages written in multiple programming languages. These example packages share the same indicators of compromise that have gone undetected for years. A “junkeldat” PyPI package for Python applications, for example, that has been compromised also shows up in a Ruby version of the package.

    Tzachi Zornstain, head of supply chain security for Checkmarx, said much like any other development team that uses multiple programming languages, it appears cybercriminals are also sharing techniques. These examples highlight the need for development teams to share security intelligence even if they build applications using different programming languages, he added. There is a tendency for development teams using one programming language to ignore application security issues that appear to only impact applications written in another programming language, noted Zornstain.

    The fact that the packages remained undetected for such a long period of time is due—at least in part—to the lack of information sharing in the ecosystem, said Zornstain.

    Cyberattackers are, of course, trying to take advantage of the implicit trust many development teams have in open source projects. However, now that more cybercriminals are making a concerted effort to compromise downstream software components, it’s imperative that every component be vetted, said Zornstain. In fact, organizations should not use any code provided by strangers, he advises.

    The core issue is that many open source projects are maintained by a small number of programmers contributing their time and effort to building components that others are free to use. Many of them argue that the onus for making sure software is secure is on the organizations that decide to deploy that software. Nor is it their responsibility to keep track of cybercrimimals distributing malicious versions of their software.

    Unfortunately, many IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may be only a matter of time before these long-simmering open source software security concerns boil over into a larger crisis.

    One way or another, DevSecOps best practices will need to be applied to application development at a deeper level. Organizations can’t assume that the software components they are relying on have been scanned for vulnerabilities by someone else. It’s simply too easy for a development team to make a mistake. The need for higher levels of security may lengthen the development process, but the alternative—malware infestations wreaking havoc—is far less desirable.

  • Stytch Launches New, Flexibility-First SDK

    Stytch Launches New, Flexibility-First SDK

    Passwordless solutions have been a trend for a while now, improving user experience (UX) while reducing exposure to common attack vectors. Now, Stytch’s new JavaScript SDK aims to make password-free authentication a bit easier by increasing customization and flexibility while offering fully baked authentication out of the box.

    Julianna Lamb, Stytch CTO, said the solution provides dual benefits by doing the heavy lifting of implementation while providing the flexibility to create a powerfully branded UX from the customer’s first sign-on experience. The Stytch JavaScript SDK can offer an all-in-one experience that handles the entire user auth journey with a pre-built frontend component. But it can also give teams complete control over designing a sophisticated and tailored authentication journey. In an era where tech companies chase the ultimate customer experience as their holy grail, this should appeal to teams wanting to improve a customer’s first impression of their brand, Lamb said.

    Multiple Options for a Smarter Front Door

    Like many authentication tools, Stytch’s product suite originally offered two options: One was a standard widget to handle frontend components while backend APIs provided logins. The other option provided direct API integration, in which the developers built their frontend, handled tasks like session management and setting cookies on the frontend and used the API to do things like send a one-time passcode or email a magic link.

    “But we found people really want flexibility when it comes to any solution they’re using,” Lamb said. “They also don’t want to do the heavy lifting when it comes to things like session management. Those things can be complex to reason through and having those out of the box is really compelling.”

    The new SDK decouples drop-in UIs from helper functions, giving teams multiple options. They can place Stytch’s UI components anywhere they want in the product, sculpting the authentication flow to their specifications. As a headless SDK, it can be embedded client-side in the application to handle all the calls to the API, do the authentication, create a session and check its validity. The result: Less backend code to write and less logic to implement.

    Customizable UI flows mean that teams can fully own the UX experience and build a UI that is customized exactly how they want it to look—and they can do this without having to build an internal API to route authentication requests from client to server. Teams looking for ways to make a brand impact right out of the gate can capitalize on this ability by creating a unique user experience.

    “Authentication is the front door to your application,” Lamb said. “Sign-up is the first impression the user has of your app—and the ability to customize it with your brand look and feel so the UI fits your aesthetic is super-critical.”

    Frictionless Flexibility in Identity Verification

    Because teams may have different authentication needs within one product, the SDK can be used in tandem with the core Stytch API to meet shifting needs. Teams could generate embedded magic links via the API while providing Google OAuth and Google One-Tap sign-in options via the SDK.

    The solution also reduces friction by making it easier to not only authenticate users but verify them on return visits to continue the same session. By loading the SDK on the frontend, teams can automatically connect Stytch’s sessions product to the browser cookie, feeding user session data directly into the cookie.

    The Stytch team is currently building out more SDK functionality and frontend components, Lamb said. Given the ongoing evolution of simple authentication tools that meet complex requirements, it will be interesting to see where innovative authentication goes next.

     

  • Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

    Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

    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: Bluesky—Twitter’s research spinout—opens its ADX algorithm, Irish data center electricity worries grow, and Apple employees are the latest to rise up against hybrid working. (more…)

  • Pulumi Extends Infrastructure-as-Code Reach

    Pulumi Extends Infrastructure-as-Code Reach

    At its online PulumiUP conference, Pulumi announced it will make its Pulumi CrossCode translation technology available to third parties and DevOps teams. The technology was developed to integrate a wide range of programming languages with its infrastructure-as-code (IaC) platform.

    The company also announced it has added support for YAML—widely used to configure Kubernetes environments—as well as any variant of Java. It already supports .NET, Node.js, Go and Python programming languages.

    Finally, Pulumi also added packages for Oracle Cloud, Databricks and EventStore that simplify deployments on those platforms. The company already provides similar integrations for Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes, Auth0, CloudFlare, Confluent Cloud, Datadog, DigitalOcean, Docker, GitHub, Kong, MinIO, MongoDB Atlas, PagerDuty, Snowflake, Spot by NetApp and SumoLogic. There are also now components that provide support for container applications, Kubernetes clusters and serverless applications along with an AWS Cloud Development Kit (CDK).

    Pulumi has been making a case for an IaC approach that enables developers to use programming languages they already know to provision infrastructure as an alternative to having to deploy and master tools such as Terraform.

    The Pulumi CrossCode translation technology the company developed is now being made available to any organization that wants to add support for another programming language. It converts any infrastructure-as-code format, including Terraform, CloudFormation, Azure Resource Manager and Kubernetes configuration, to any programming languages supported by Pulumi.

    Pulumi CEO Joe Duffy said the goal is to extend the overall reach of the translation technology the company created to simplify provisioning any type of infrastructure.

    While many developers use tools such as Terraform, the need to limit misconfigurations is driving many larger enterprises to revisit their approach to IaC to improve software supply chain security, noted Duffy. Today, Pulumi claims more than 2,400 organizations have adopted platforms that enable developers to provision infrastructure and apply guardrail policies to reduce errors. That approach prevents developers from making configuration mistakes that can lead to exfiltration of data via, for example, a port that has been accidentally left open, he added.

    Too many developers assume that their cloud service provider is securing both the underlying platform and how it is configured only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned without some ability to apply policies that enforce rules for provisioning that infrastructure within the context of a larger DevSecOps workflow.

    Ultimately, the goal is to employ automation to resolve these issues once and for all as more organizations adopt DevSecOps best practices. In the meantime, the challenge is doing so in a way the average developer will accept and embrace. Otherwise, they will continue to find ways to work around security teams in the name of productivity, regardless of how insecure the underlying IT environment might become.

  • Smoothing the Transition From REST to GraphQL

    Smoothing the Transition From REST to GraphQL

    Since its open source release in 2015, GraphQL has taken the development world by storm. GraphQL, the query language originally developed by Facebook, is a big boon for frontend developers, as it enables you to grab the exact data you need with a single request. This solves the problems of over-fetching and under-fetching, which classical REST APIs are prone to. GraphQL also offers a nice developer experience with a consistent schema and documentation. Some are even treating GraphQL as a convenient meta layer to aggregate multiple underlying services and abstract their interfaces with simple commands.

    For these reasons and more, many development teams are considering switching from REST to GraphQL. Even enterprises are beginning to use GraphQL in large production environments. But, how can these teams make the switch without breaking existing integrations? How can we ensure that things like developer experience, security, and access control all remain stable?

    I recently met with Anant Jhingran, the co-founder of StepZen, to discover tips for transitioning from REST to GraphQL. According to Jhingran, most organizations see the benefit in adopting GraphQL but are hesitant to forgo years of investment into RESTful architectures. But according to Jhingran, it’s rarely a case of “either/or”—more often, he sees projects running both styles simultaneously or layering one on top of the other. Below, we’ll explore some things to keep in mind as you invest in GraphQL.

    The Decade of Developers

    We’ve reached ubiquity of web APIs among companies big and small. “APIs have turned out to be phenomenal for software supply chains,” said Jhingran, the former CTO of Apigee. They help share data between partners and can enable platform ecosystems to thrive. Jhingran describes how within the last decade, APIs and API management have peaked to near-ubiquity in terms of adoption.

    But not all APIs behave the same way. Although representational state transfer (REST) is the most popular style, it’s still quite a general architectural guideline for web APIs—how the data comes out of each service is still highly nuanced. The structure of requests and responses are different from service to service, causing developer experience hangups at scale.

    GraphQL, on the other hand, “is a fantastic way of structuring data,” said Jhingran. With a single call, you can return the explicit information that the client requires in an expected format. For an e-commerce application, for example, this might be customer information, order numbers and delivery status. Displaying this all with one call is an awesome experience for frontend developers. And, GraphQL APIs are easy to explore and navigate since the schema is baked in. This improves upon REST APIs, where documentation may not always match the actual production implementation.

    “This decade is the decade of developers,” said Jhingran. Satisfying developer experience has become more mission-critical as enterprises work to increase their footprint in the cloud marketplace and GraphQL is part of this movement. “For people who build apps, it’s just better,” said Jhingran.

    But just because frontend teams clamor for the ease of use of GraphQL doesn’t mean backend teams can easily restructure their entire framework around it. Doing it right requires many skills, and the journey can be arduous, explained Jhingran.

    It’s Rarely REST Vs. GraphQL

    REST and GraphQL are often pitted against one another to the point that they seem like polar opposites. But in practice, teams often use GraphQL to build on top of APIs already in place. Jhingran describes the most common pattern as “GraphQL comes in as a layer that connects the dots between various REST APIs.” Either GraphQL is consumed directly or as a REST layer above GraphQL. “It could go either way,” he said.

    GraphQL is a fantastic data infrastructure tier as it can mix and match database backends. It could, in essence, become the new plumbing upon which applications are constructed. But while GraphQL may be excellent for internal construction, the name of the game is stability when externalizing services to the outside world. With REST, the big goal is to decrease broken clients and ensure high-grade security for each resource. Therefore, Jhingran foresees certain use cases where using a REST wrapper around GraphQL services to deliver fixed JSON responses would be preferred.

    Another point is that GraphQL is not only relegated to appeasing frontend developers—it has some backend potential, too. “GraphQL is an opportunity to reimagine frontend and GraphQL is an opportunity to reimagine backend infrastructure,” said Jhingran. This concept has weight nowadays, as Netflix engineers, for example, use GraphQL as a backend for microservices architecture.

    Making the Transition From REST to GraphQL

    Not all apps are going to be transformed on day one. Teams may encounter cultural resistance to new technologies. Interface redesigns, especially for those external apps which are exposed to third parties, must also require extra precaution to maintain app compatibility to avoid breaking change.

    Thus, it may take time to transition effectively. “Getting it started versus getting it right are not the same thing,” said Jhingran. He said people who get started with GraphQL may struggle for months due to competing best practices and tools. For example, Jhingran identified two main perspectives when approaching GraphQL: Programming and declarative.

    • Programming: Teams use GraphQL libraries such as Apollo to program their way out of your GraphQL endpoint. In this approach, you just start writing. It’s quick to get started, said Jhingran, but you end up describing everything you do and encountering many contingencies along the way.
    • Declarative: The other option is a more declarative approach—instead of telling the system how, you tell it what to do. For example, this subsystem should do X, this subsystem should do Y and so on. According to Jhingran, adopting tooling with declarative snippets to create GraphQL endpoints is “better in the short and long run.”

    GraphQL Security

    A March 2022 report from Salt Labs found a shocking 681% increase in API-based cyberattacks over the previous 12 months. There are many concerns surrounding API security right now—these valuable endpoints are prone to broken access control, data overexposure and over-permissive states.

    As I’ve covered previously, GraphQL security is a bit nuanced compared to REST. Within the REST paradigm, you can easily assign permissions and rate limit calls per resource. But with GraphQL, it’s not that simple. Since you can batch multiple queries, callers have much more power at their fingertips, and hackers might abuse such power if the proper authorization isn’t in place.

    Companies may rightly worry about opening another can of worms with GraphQL. But according to Jhingran, these worries are all solvable. A comprehensive GraphQL endpoint will likely require another layer to uniquely segment authorization to retain a least-privilege model for all resources and backend endpoints.

    Future of GraphQL

    To date, GraphQL has gained modest prominence. But, Jhingran foresees an incoming inflection point in the next two to three years. “The dominoes are beginning to fall,” he said.

    Now that the market is saturated with APIs, characteristics outside of functionality will be what sets a service apart and gives it a competitive edge. This includes things like performance, security and developer experience, the latter of which makes GraphQL an attractive proposition. This, paired with the explosion in GraphQL tools, will undoubtedly help developers perform their jobs better.

    Looking to the future, Jhingran predicts increased usability and abstraction in how developers work with GraphQL. He compared it to how disjointed pages on the web became interconnected and searchable with links. We see similar thinking happening in the world of APIs, he explained, in which the disjointed APIs require a better connection. Similar to how Google simplified search, he foresees GraphQL and the tools that work with it helping to decrease cognitive load by abstracting complexity with declarative commands.