Starting today, administrators using Github.com accounts can enable their repositories and/or organizations to run Dependabot updates jobs as a GitHub Actions workflow using both hosted and self-hosted runners. Running Dependabot does not count towards GitHub Actions minutes–meaning that using Dependabot continues to be free for everyone.

Since its launch, Dependabot has used hosted compute to simplify the process of running update jobs, minimizing the amount of work developers need to do to stay on top of security vulnerabilities. However, this compute system wasn’t able to access some on-premises resources like private registries–a growing best practice outlined in frameworks like S2C2F–and it wasn’t as flexible as it could be. Further, as GitHub Actions has become more ubiquitous over the years, users told us they wanted to see the logs for all their jobs in just one place.

To tackle these challenges, GitHub is consolidating Dependabot’s compute platform to GitHub Actions, and jobs that generate pull requests can now be run as GitHub Actions workflows. This allows Dependabot to leverage GitHub Actions infrastructure, including connecting Dependabot to self-hosted runners. With this change, users can choose to run Dependabot on their private networks with self-hosted runners, allowing Dependabot to access on-premises private registries and update those packages. Developers will see performance improvements, like faster Dependabot runs and increased log visibility. APIs and webhooks for GitHub Actions can also detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines.

For more information on how to enable your repositories with Dependabot as a GitHub Actions workflow, please see our documentation for Dependabot on GitHub Actions runners. If you’d like to learn more about or enable self-hosted runners, check out the differences between hosted and self-hosted runners.

Over the course of the next year, Dependabot will also migrate all update jobs to run on GitHub Actions. This migration will include faster runs, increased troubleshooting visibility, self-hosted runners, and other performance and feature benefits. For most users, the transition will be seamless; however, if your organization has disabled GitHub Actions by policy, your administrators will receive instructions about how to update your configuration to ensure that the Dependabot service is not interrupted.

Up next for Dependabot: in addition to gathering your feedback on Dependabot on the GitHub Actions compute infrastructure, the team is working to support additional dependabot.yml configuration options for multiple directories and multiple ecosystems. Keep an eye on the GitHub Changelog for more and please let us know what you think by contributing to our community discussion!

The post Dependabot on GitHub Actions and self-hosted runners is now generally available appeared first on The GitHub Blog.

There’s an increasing need across enterprises and the open source ecosystem to have a verifiable way to link software artifacts back to their source code and build instructions. And with more than 100M developers building on GitHub, we want to ensure developers have the tools needed to help protect the integrity of their software supply chain. Today, we’re proud to announce the public beta of Artifact Attestations, a new feature that will pave the way for a cultural shift toward expecting to know where software comes from.

Artifact Attestations allow project maintainers to effortlessly create a tamper-proof, unforgeable paper trail linking their software to the process which created it. Downstream consumers of that metadata can then use it as a foundation for new security and validity checks through policy evaluation via tools like Rego and Cue. We’re starting with verification support based on GitHub CLI, but will expand to bring these same controls to the Kubernetes ecosystem as well later this year.

Artifact Attestations is powered by Sigstore, an open source project for signing and verifying software artifacts. This means open source maintainers can reduce their project’s exposure to supply chain attacks and increase the security of the broader software ecosystem–no matter where maintainers host their code, or build their artifacts. Let’s jump in.

An effortless user experience

Security features need to be more than just powerful—they have to be simple to adopt and easy to configure in order to be effective. Artifact Attestations couldn’t be easier to set up: all you need to do is add a bit of YAML to your GitHub Actions workflow to create an attestation and install the GitHub CLI tool to verify it.

1. Enable your GitHub Actions workflow to write to the attestations store:

   permissions:
     id-token: write
     attestations: write
     contents: read
   

2. Direct a workflow to create an attestation, making sure to place it after the artifact is generated:

       - name: Attest Build Provenance
           uses: actions/attest-build-provenance@897ed5eab6ed058a474202017ada7f40bfa52940 # v1.0.0
           with:
           subject-path: "bin/my-artifact.tar.gz"
   

3. Once your build is finished and you have the artifact downloaded, use GitHub CLI (version 2.49.0 or greater) to verify it, providing the name of the organization that contains the repository where the action ran:

   gh attestation verify my-artifact.tar.gz -o my-organization
   

It’s also easy to download the attestation document itself for storage or offline verification (for example, in an air-gapped environment), quickly look at certificate details, or extract verified attestation contents in a JSON form so you can pipe it to a policy engine like OPA.

package attestation.slsa1
import future.keywords.if

approved_repos := [
    "https://github.com/sigstore/sigstore-js",
    "https://github.com/github/example",
]

# Fail closed
default allow := false

# Allow if the repository is in the approved_repos list and the predicateType matches
allow {
    some i
    # Check if the predicateType matches the required type
    input[i].verificationResult.statement.predicateType == "https://slsa.dev/provenance/v1"

    # Attempt to safely assign the repo variable
    repo := input[i].verificationResult.statement.predicate.buildDefinition.externalParameters.workflow.repository

    repo == approved_repos[_]
}

You can grab the attestation in JSON format and use the policy to verify myfile.zip came from an allowed repository in the policy like so:

$ gh attestation verify -R github/example --format json myfile.zip | \
opa eval  --stdin-input -f raw \
-d policy.rego "data.attestation.slsa1.allow == true"

true

Can I attest other things in my build, like SBOM?

If you have an SBOM that you’ve generated as part of your build, you can use the new attest-sbom action to associate it with a final artifact. You simply provide the path to that artifact and the action will take care of wrapping it in an in-toto attestation predicate, signing it with our internal Sigstore instance, and sending it to our attestation store. If you don’t already have an SBOM in your build and want a way to get started, the anchore/sbom-action offers support for container images and many language ecosystems.

To associate a build artifact with an attested SBOM, follow these steps:

1. First (just like for provenance) you need to grant write permission for the attestation store to your workflow:

   permissions:
     id-token: write
     attestations: write
     contents: read
   

2. Ensure that you actually have an SBOM that makes sense for your particular needs. Here’s an example of using Anchore’s Syft to scan a build directory:

   - uses: anchore/sbom-action@v0
     with:
       path: ./build/
       format: 'spdx-json'
       output-file: 'sbom.spdx.json'
   

3. Finally, use the attest-sbom action to wrap the generated SBOM file contents in an in-toto SBOM predicate, sign it, associate it with your built artifact, and send it to the attestation store:

   - uses: actions/attest-sbom@v1
     with:
       subject-path: 'bin/my-artifact.tar.gz'
       sbom-path: 'sbom.spdx.json'
   

How it works

Artifact Attestations help reduce the complexity of deploying and managing public key infrastructure, instead placing trust in the security of your GitHub account. We accomplish this by signing a document with a temporary keypair. The public key is attached to a certificate associated with a build system’s workflow identity, and the private key never leaves process memory and is discarded immediately after signing. This differs from other signing approaches that rely on human identities or long-lived keys. We believe that certificate revocation lists are too problematic to use effectively, and that the future of software provenance and signatures goes through workload identity. Here’s how:

• When an attestation action executes, our Sigstore client requests the GitHub Actions OIDC token associated with that workflow run. It then creates a key pair and sends the public half to Fulcio, a certificate authority, along with the OIDC token. In the case of a public repository, Sigstore Public Good Instance’s Fulcio issues the cert. In the case of a private repository, the cert is issued by GitHub’s internal instance of Fulcio, ensuring that no customer information leaves GitHub.
• When receiving the token, Fulcio validates the token’s signature and mints a new short-lived X.509 certificate binding the public key to the workflow’s OIDC identity.
• Fulcio returns the certificate to the client running in GitHub Actions, which calculates a SHA-256 digest of the subject artifact, and writes out an in-toto statement which binds the subject to a predicate containing data from the OIDC token’s claims.
• The client uses the private key to seal the in-toto statement in a DSSE signing envelope. Then, it throws the private key away. The envelope’s signature is sent to the TSA for a timestamp counter-signature, which proves that the signature was produced during the certificate’s 10-minute validity window.
• Everything is wrapped up as a Sigstore bundle and persisted to GitHub’s attestation store. In the case of a private repository, that’s the end of the flow. In the case of a public repository, the attestation is additionally written to the Sigstore Public Good Instance and lands on Rekor, the project’s immutable ledger.

Artifact Attestations have been in an early access preview for the last several months, and we’re thrilled by the early feedback we’ve received.

GitHub is steadfast in its commitment to democratizing software attestations and artifact integrity. Leveraging just six lines of code in GitHub workflows marks a game-changer in build chain security—an initiative I've utilized, experienced, and enthusiastically embraced.

GitHub is now a root certificate authority

When we started designing the requirements for this feature, we realized quickly that we wanted users to be able to sign an artifact on GitHub Actions and then verify it anywhere, even offline. Public key infrastructure (PKI) is complex and high-stakes, and we heard from both customers and open source projects that they wanted a way to sign things without having to build out PKI or manage secrets which can be leaked or lost. To do this, we first needed to establish GitHub as a root certificate authority (CA) for signing software so that we could own the entire certificate chain.

In October 2023, we went live with an X.509 certificate authority and RFC 3161 timestamp server, with a trust root managed via a quorum of hardware tokens held by employees across a variety of geographies and roles. The trust root is managed with tooling from the TUF project (where we’re contributors), and the CA and timestamp services are instances of Sigstore applications. Intermediate certificates are housed in Azure KeyVault Managed HSMs, which are used to sign leaf certificates issued by Sigstore Fulcio and Sigstore Timestamp Authority. Signing certificates are valid for 10 minutes from the time of issuance, so there is no need to manage the complexities of Certificate Revocation Lists (CRLs).

Sigstore, in public and in private

In keeping with our commitment to offering cutting-edge features to both enterprise customers and the open source community, Artifact Attestations supports the same user experience offered in two basic modes depending on repository visibility. For public repositories, attestations generated on GitHub Actions will be written to the Sigstore Public Good Instance for verification in public on an immutable ledger. For private repositories on GitHub Enterprise plans, the attestations are written to an internal, completely private database and no information is written to public ledgers or logs.

A more secure future

It’s important to note that provenance by itself doesn’t make your artifact or your build process secure. What it does do is create a tamper-proof guarantee that the thing you’re executing is definitely the thing that you built, which can stop many attack vectors. It’s still vital to maintain strong application security processes like requiring code review for all patches, and applying dependency updates in a timely manner.

In other words: attestations provide you with a paper trail, which cannot be forged, tying a given artifact to a given GitHub Actions workflow run. We believe that this is a key piece of the modern trust model, and in addition we want to help effect a cultural shift toward folks knowing where their software components come from.

Artifact Attestations will allow customers unprecedented visibility into the composition and usage of their built software artifact, and this is just the beginning. We’ll be offering the ability to attest other kinds of artifacts associated with the build process, such as vulnerability reports and other pieces of metadata supported by the in-toto project’s defined predicate types. Look for exciting news around Kubernetes support, new guarantees for releases, and more later this year.

The post Introducing Artifact Attestations–now in public beta appeared first on The GitHub Blog.

May 16 is Global Accessibility Awareness Day (GAAD), and I’m using the occasion to reflect on one of the longest, if not the longest, projects I’ve worked on throughout my accessibility design career: Web Accessibility (A11y) Design Bootcamp. In talking to fellow web accessibility practitioners and folks who work in product development, I often get asked what the bootcamp is, how we got started, and how they can do the same in their organizations. Let’s break all of that down!

What is A11y Design Bootcamp?

A11y Design Bootcamp is a live educational program that consists of exercises, discussions, and knowledge shares to raise awareness of web accessibility best practices, the role designers play in creating accessible products, and how to advocate for accessibility with cross-functional partners. Topics we cover include: what is web accessibility, assistive technology and how it works, identifying bugs in wireframes and in build, and disability justice, or what I like to call “bringing it back to the people.”

Currently, a cohort meets for four sessions over two weeks. Bootcamp utilizes a reverse classroom model, meaning designers complete pre-work prior to each session, such as bespoke videos, documentation, and articles, so we can utilize our time together through exercise and discussion. Each round consists of pre- and post-bootcamp surveys that allow us to iterate each cohort and ensure it is meeting designers’ needs. Adaptations are made to fit the course material, and breaks are introduced to make sure attendees digest material without overwhelm. Additionally, we use a Slack channel to send reminders and review messages with each cohort.

Since its inception in March 2023, I’ve facilitated four cohorts that mount to 50% of our design organization here at GitHub completing training–and counting!

Building a bootcamp

Having prior experience running live web accessibility education programs, content creation was more or less straightforward. What was more difficult was figuring out how to connect these programs to larger team and organization goals.

In preparation for our first bootcamp, Catharine McNally, a program manager focused on accessibility, led a few stakeholders through an awesome brainstorm that helped us ground our content. Some questions posed included:

• What will make this training “sticky?”
• How will we set a good first impression (First impressions are everything!)?
• What will make attendees excited to come back the next session?
• What do we want attendees to feel, think, and do differently after bootcamp?
• When attendees think back to this bootcamp, what will they remember?
• What does success look like for the facilitation team?

During this time, we also worked through important information, such as:

• Identifying false narratives that designers might have (such is, “Accessibility stifles my creativity”) and what we could do to debunk them.
• Tools for being proactive versus reactive in the product development process.
• The importance of alignment to the A11y Design team’s values of being approachable, helpful, and nonjudgmental.

Bootcamp values

As a facilitator, the best part of the grounding exercise discussed above was establishing A11y Design Bootcamp values. This felt integral because everything we did–every exercise, discussion, slide, and both spoken and written word–was in service to four principles:

• Relevant. Our material needs to resonate with designers. Otherwise, how is it going to stick? Building “plug and play” modules really helped here as it allowed us to create exercises we could use again and again.
• Engaging. Let’s face it, no one likes mandatory training, let alone boring training. In providing interactive exercises and discussions, we reinforce what we teach while also developing trust, which is key for encouraging designers to ask questions.
• Actionable. We asked ourselves “Could a designer apply something they learned in A11y Design Bootcamp 10 minutes after the session ended? A day? A week?” This greatly informed how to present content.
• Safe. As a facilitator, this is the most important element of bootcamp. Trust must be built to demonstrate that there really is no such thing as a silly question–in fact, attendees are in bootcamp to do just that! It’s my job to ensure every attendee feels psychologically safe and can learn without fear of judgment.

Why live training?

Tangentially related, I often get asked “Why a live workshop? That’s so much work!” I promise it’s not just because I like socializing. In fact, live facilitation is in alignment with all of the our values because it:

• Is easy to adapt. Especially with new material, live content can be easily adapted and iterated to reflect the most relevant interest of the team with less turnaround time than producing a video.
• Allows for live questions. Attendees have the opportunity to learn with and from peers through discussions and thoughts that arise from questions asked in class.
• Promotes community-centered learning. Going through the same content at the same time can help prompt discussion and cross-collaboration within the cohort, building trust. In addition, because GitHub is primarily remote, this is a great time for team building and connection that is reminiscent of being together in an office.
• Is inclusive of learning styles. Many trainings are essentially long documents that offer no opportunity to engage with others. In live training, we remove barriers associated with reading (comprehension, speed, dyslexia, dyscalculia, and more), and open learning up for folks who retain information better in real time.

Key takeaways

• Meet teams where they’re at. Start small. Do your research on where teams are at in terms of web accessibility and go the extra mile to make it valuable. In my experience, it’s high risk, high reward.
• Go where you’re wanted. A manager’s apathy versus advocacy for a program, especially a pilot program, makes a huge difference for both organizers and participants! Bootcamp wouldn’t be in the same place if it hadn’t been for managers advocating to take the time to train their teams.
• Be adaptable and open to change. While I’m a facilitator, I’m by no means an educator. Having a flexible mind and curriculum allows for surprises and turns that, more often than not, improve bootcamp. For instance, embracing the reverse classroom model came from an a11y engineer during a coffee chat. My seminar on AI, accessibility, and inclusive design, which I created midway through our second cohort because of demand, remains one of the most engaged and commented topics in bootcamp.
• Collect metrics and write documentation. If we didn’t, we wouldn’t know how much people loved live facilitation and bringing disability back to being about people (Session 4). We iterate every session just a little bit. In addition, documentation helps with sharing responsibility and scaling.
• Strive for co-creation. When we think about scaling, the goal isn’t for everyone on the team to be a top tier facilitator. It’s to share the load so more folks can participate, including past attendees as a way to level up their skills.

Looking forward

While we’ve made great strides, there’s still a big journey ahead of us! We intend to create boot camps for more product design teams and use the frameworks we have to scale bootcamp to other functions.

I personally want to thank Allie Thu for the opportunity to lead this project, and Catharine McNally for all the ways she’s helped this program grow, and both for their unwavering support and enthusiasm. I’m grateful my job includes fostering designers’ appreciation and dedication to designing accessible products, and that I get to lead a training program that continues to grow with them.

---

• For more info and to learn how our Accessibility Champions Program works together with A11y Design Bootcamp, or to hear all this information in an audio-forward format, watch GitHub’s Accessibility Education Ecosystem presentation from axe-con 2024. Free registration required.
• For more information about GitHub Accessibility, please visit accessibility.github.com and share feedback on our accessibility community discussion page.

The post Celebrating 1 year of A11y Design Bootcamp: Takeaways and tips appeared first on The GitHub Blog.

Are you passionate about creating engaging content for the tech community? Do you enjoy sharing your coding journey with others? If so, our new JetBrains Content Creators Program is just the thing for you!

At JetBrains, not only do we work to provide an exceptional developer experience, but we also strive to inspire and support as many coders as possible. Through our new Content Creators Program, we empower content creators by awarding both them and their audiences with access to JetBrains IDEs, no matter what technology stack they prefer.

Who can participate in the JetBrains Content Creators Program?

Our program is open to creators who produce various types of content, including videos, tutorials, livestreams, podcasts, social media posts, newsletters, and more. If you already have an established audience of at least 2,000 followers and consistently produce new content, we’d love to partner with you!

What are the benefits of joining?

By becoming a part of the JetBrains Content Creators Program, you’ll gain access to a range of exciting benefits:

• Free access to all JetBrains IDEs.
• Exclusive perks for your audience: extended trials, discounts on JetBrains products, and free licenses to use as giveaway prizes to attract new followers and subscribers.
• The opportunity to expand our partnership further, as we’re open to exploring alternative offers and discovering new ways to collaborate together.

How to get involved

Interested in joining the program? Check out this page for the details and get in touch with us to learn more.

GET INVOLVED

We’re excited to partner with passionate content creators to bring the power of JetBrains tools to the developer community.

Let’s connect!

Ten years ago, Microsoft envisioned a bold future: a world free of passwords. Every year, we celebrate World Password Day by updating you on our progress toward eliminating passwords for good. Today, we’re announcing passkey support for Microsoft consumer accounts, the next step toward our vision of simple, safe access for everyone.

In 2015, when we introduced Windows Hello and Windows Hello for Business as secure ways to access Windows 10 without entering a password, our identity systems were detecting around 115 password attacks per second.¹ Less than a decade later, that number has surged 3,378% to more than 4,000 password attacks per second.² Password attacks are so popular because they still get results. It’s painfully clear that passwords are not sufficient for protecting our lives online. No matter how long and complicated you make your password, or how often you change it, it still presents a risk.

The good news is that we’ve made a lot of progress toward making passwords a relic of the past. For a while, you’ve been able to sign in to apps and websites using FIDO security keys, Windows Hello, or the Microsoft Authenticator app instead of a password. Since September 2021, you’ve not only been able to sign in to your Microsoft account without a password, but you’ve also been able to delete your password altogether.³ We’re almost there.

And now there’s an even better way to sign in to more places without passwords: passkeys.

The future of signing in

If you’re like many people, you probably still use passwords to sign in to most of your websites and apps, most likely from multiple devices. This can translate into hundreds of passwords to remember, unless you use a password manager. With passkeys, instead of creating, managing, remembering, and entering passwords, you access your digital accounts the same way you unlock your device—usually with your face, fingerprint, or device PIN. More and more apps and services are adding support for passkeys; you can already use them to sign in to the most popular ones. Passkeys are so much easier and more secure than passwords that we predict passkeys will replace passwords almost entirely (and we hope this happens soon).

Starting today, you can use a passkey to access your Microsoft account using your face, fingerprint, or device PIN on Windows, Google, and Apple platforms. Your passkey gives you quick and easy access to the Microsoft services you use every day, and it will do a much better job than your password of protecting your account from malicious attacks.

Easier and more secure than passwords

Think of how many times and places you sign in with a password every single day. Is it 10? 50? Not only is this a frustrating experience, it’s also an unreliable way to protect a digital account. Here’s why: When you enter a password to sign in to an account, you’re essentially sharing a secret with the website or app to prove that you should have access to the account. The problem is that anyone who gets a hold of this secret can gain access to your account, and if your password gets compromised and appears on the dark web, the repercussions can be serious.

To make your credentials stronger, an app or website might require you to make your password longer or more complex. But even if you follow all the best practices for creating “strong” passwords, it’s still a trivial exercise for hackers to guess, steal, or trick you into revealing them.

You may have experienced an attack yourself—you click on a link in an email that seems legitimate, which leads to a website that looks just like the one you’re used to, asking you to enter your credentials. But when you do, nothing happens, or you get an error message. By the time you notice that the URL in your browser address bar is different from the usual one, it’s too late. You’ve just been phished by a malicious website.

Many app and website providers understand that even complicated passwords aren’t good enough to protect your account, so they give you the choice to use two-step or multifactor authentication with approvals and codes sent to your phone, email, or an app. While traditional multifactor authentication can help protect your account, it’s not attacker-proof, and it creates another frustrating barrier between you and your content: all these access attempts, passwords, and codes on all your devices can really add up.

This is why we’re so enthusiastic about passkeys.

How passkeys work

Passkeys work differently than passwords. Instead of a single, vulnerable secret, passkey access uses two unique keys, known as a cryptographic key pair. One key is stored safely on your device, guarded by your biometrics or PIN. The other key stays with the app or website for which you create the passkey. You need both parts of the key pair to sign in, just as you need both your key and the bank’s key to get into your safety deposit box.

Because this key pair combination is unique, your passkey will only work on the website or app you created it for, so you can’t be tricked into signing in to a malicious look-alike website. This is why we say that passkeys are “phishing-resistant.”

Even better, all the goodness and strength of cryptographic authentication stays behind the scenes. All you have to do to sign in is use your device unlock gesture: look into your device camera, press your finger on a fingerprint reader, or enter your PIN. Neither your biometric information nor your PIN ever leaves your device and they never get shared with the site or service you’re signing in to. Passkeys can also sync between your devices, so if you lose or upgrade your device, your passkeys will be ready and waiting for you when you set up your new one.

The best part about passkeys is that you’ll never need to worry about creating, forgetting, or resetting passwords ever again.

Creating a passkey for your Microsoft account

Creating a passkey for your Microsoft account is easy. On the device where you want to create the passkey, follow this link, and choose the face, fingerprint, PIN, or security key option. Then follow the instructions on your device.

To learn more about creating passkeys for your Microsoft account, visit this guide.

Signing into your Microsoft account using a passkey

When you sign in to your Microsoft account, you can use your passkey by choosing Sign-in options and then selecting face, fingerprint, PIN, or security key. Your device will open a security window, and then you can use your passkey to sign in.

Figure 1. Signing in to your Microsoft account on mobile devices.

Today, you can use a passkey to sign in to Microsoft apps and websites, including Microsoft 365 and Copilot on desktop and mobile browsers. Support for signing into mobile versions of Microsoft applications using your passkey will follow in the coming weeks.

If you want to use passkeys to sign in to work-related apps and services, your admin can configure Microsoft Entra ID to accept passkeys hosted on a hardware security key or in the Microsoft Authenticator app installed on your mobile device.

In this era of AI, there’s unprecedented opportunity for creativity and productivity that empowers every person on the planet—including billions of Microsoft users who access services for work and life every day—to achieve more. Protecting and accessing your digital life doesn’t need to be a hassle, and you shouldn’t have to choose between simple access and safe access. Accessing your Microsoft account with a passkey lets you put the frustration of passwords and codes behind you, so you can focus on being creative and getting things done.

Happy World Password(less) Day!

Learn more

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

---

¹Microsoft Password Guidance, Microsoft Identity Protection Team.

²Microsoft Entra expands into Security Service Edge and Azure AD becomes Microsoft Entra ID, Joy Chik. July 11, 2023.

³The passwordless future is here for your Microsoft account, Vasu Jakkal. September 15, 2021.

The post Microsoft introduces passkeys for consumer accounts appeared first on Microsoft Security Blog.

The articles provide performance tips for Microsoft .NET, focusing on code analysis and benchmark data. They demonstrate settings to enhance application performance with examples. All recommendations relate to .NET 8.