Security Boulevard

In the world of managed service providers (MSPs), staying ahead of the curve requires constant innovation, particularly in data management and operational efficiency. I recently had the opportunity to interview Callen Sapien, President and acting Chief Security Officer (CSO) of MSPBots on the show floor of the Build IT event in Orlando, FL, to explore

The post Unlocking New Potential with MSPBots: A Conversation with Callen Sapien appeared first on Seceon Inc.

The post Unlocking New Potential with MSPBots: A Conversation with Callen Sapien appeared first on Security Boulevard.

4 min read Just when I thought I was out, they (non-human identities and a young startup named Aembit) pulled me back in.

The post Why I Came Out of (Pseudo) Retirement to Help Solve the Non-Human Identity Challenge as Aembit’s CISO appeared first on Aembit.

The post Why I Came Out of (Pseudo) Retirement to Help Solve the Non-Human Identity Challenge as Aembit’s CISO appeared first on Security Boulevard.

Despite slower hiring trends and tighter budgets, chief information security officer (CISO) compensation continues to rise, with the average U.S.-based CISO earning $565K, and top earners exceeding $1 million.

The post Average CISO Compensation Tops $500K appeared first on Security Boulevard.

MEDIA ADVISORY Leading experts to share insights on using orchestration to protect legacy identity systems with modern cloud identity platforms without code rewriting  BOULDER, Colo., Oct. 2, 2024 – Strata Identity, the Identity Orchestration company, today announced it will host a free webinar on October 3rd with CyberArk on how to eliminate the costly, time-consuming...

The post Strata Identity and CyberArk to Host Webinar on Transforming Legacy Identity by Embracing Modern IAM appeared first on Strata.io.

The post Strata Identity and CyberArk to Host Webinar on Transforming Legacy Identity by Embracing Modern IAM appeared first on Security Boulevard.

Silver Spring, Maryland, 2nd October 2024, CyberNewsWire

The post Mario Duarte, Former Snowflake Cybersecurity Leader, Joins Aembit as CISO to Tackle Non-Human Identities appeared first on Security Boulevard.

Canonical has released security updates for Ubuntu 16.04 ESM and Ubuntu 18.04 ESM to address multiple vulnerabilities in Git, a powerful and widely-used distributed version control system. These vulnerabilities may allow malicious attackers to overwrite files outside the repository, inject arbitrary configuration, or even execute arbitrary code. In this article, we’ll explore the details of […]

The post Addressing Git Vulnerabilities in Ubuntu 18.04 and 16.04 appeared first on TuxCare.

The post Addressing Git Vulnerabilities in Ubuntu 18.04 and 16.04 appeared first on Security Boulevard.

Reaching p=reject does not mean your DMARC management ...

The post What Happens After p=Reject: Beyond the DMARC Golden Standard  appeared first on EasyDMARC.

The post What Happens After p=Reject: Beyond the DMARC Golden Standard  appeared first on Security Boulevard.

As of June 30, 2024, the CentOS Project ceased all updates and releases for CentOS Linux. CentOS Stream serves as the upstream development platform for future RHEL releases. CentOS Stream 9 will continue to receive regular updates, providing users with the latest features and security patches. In December 2020, Red Hat announced a significant shift […]

The post Future of CentOS Stream 9: The Road Ahead appeared first on TuxCare.

The post Future of CentOS Stream 9: The Road Ahead appeared first on Security Boulevard.

Cybersecurity professionals are facing increasing levels of stress, with 66% reporting that their roles have become more demanding over the past five years, according to a report from ISACA.

The post Cybersecurity Professionals Operate Under Increased Stress Levels appeared first on Security Boulevard.

As per a recent Microsoft alert, a threat actor with malicious financial motives has been observed leveraging a new INC ransomware strain to target the health sector in the United States (US). In this article, we’ll dive into the details and determine who the threat actor is and how such attacks are carried out. Let’s […]

The post Microsoft Alert: New INC Ransomware Targets US Healthcare appeared first on TuxCare.

The post Microsoft Alert: New INC Ransomware Targets US Healthcare appeared first on Security Boulevard.

Simplify SOAR playbook development with an artifact-based approach. Learn to integrate tools, categorize commands, map key artifacts, and build effective playbook stages.

The post How to Build a SOAR Playbook: Start with the Artifacts appeared first on D3 Security.

The post How to Build a SOAR Playbook: Start with the Artifacts appeared first on Security Boulevard.

Authors/Presenters:Nirav Atre, Hugo Sadok, Justine Sherry

Our sincere thanks to USENIX, and the Presenters & Authors for publishing their superb 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI '24) content, placing the organizations enduring commitment to Open Access front and center. Originating from the conference’s events situated at the Hyatt Regency Santa Clara; and via the organizations YouTube channel.

Permalink

The post USENIX NSDI ’24 – BBQ: A Fast and Scalable Integer Priority Queue for Hardware Packet Scheduling appeared first on Security Boulevard.

Introduction

In this blog post, we will cover the basics of a source generator, the major types involved, some common issues you might encounter, how to properly log those issues, and how to fix them.

Source Generators have existed since .NET 5 was first introduced in late 2020. They have seen numerous improvements since that initial release, including the creation of newer Incremental Source Generators.

TLDR: Source generators in .NET enable you to inspect user code and generate additional code on the fly based on that analysis. The example in this blog post may seem a bit redundant, but as you use more advanced patterns, you can generate hundreds of lines of code, helping to reduce boilerplate and repetitive code across your projects. Source generators are also great for lowering runtime reflection use, which can be expensive and slow down your applications.

Skip to the real content.

While developing a C# library to perform messaging between various process components or between processes, I encountered an issue where client programs using this new messaging library would need to add a list of all the “Messenger types.” I had heard of source generators and experimented with them a small amount before encountering this problem, so I figured I could dive in and devise a working solution to handle this and inject the list of “Messenger types” as a property automagically.

I have also been learning various programming paradigms and interesting practices. Vertical Slice architecture and aspect-oriented programming (AOP) are the two relevant to this blog. Vertical slices focus on grouping things that will change together, typically by the feature they represent, regardless of the layer they belong to. The goal of the slices is to minimize coupling between slices and maximize coupling in a slice (i.e., things in a feature depend on each other while trying not to rely on other slice features). This keeps the code base modular and makes it easy to update, remove, or add new slices, as the changes shouldn’t directly affect existing slices. [You can read more on vertical slices here]

AOP is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. Typically, in C#, this is implemented by creating attributes that are then placed on classes, methods, etc., to introduce or modify the decorated code. So, with these things in mind, I wanted to look at creating a feature that worked with vertical slices using AOP, and given my newfound challenge of automatically injecting a list of objects into my messenger app at build time, I had just the target goal in mind to combine all of it together.

With that brief overview of why I started messing with source generators, let’s take a quick step back and cover the basics of what a source generator is, what it lets you do, and what it doesn’t.

What is a Source Generator?

According to Microsoft: “Source generators aim to enable compile-time metaprogramming, that is, code that can be created at compile time and added to the compilation. Source generators will be able to read the contents of the compilation before running, as well as access any additional files, enabling generators to introspect both user C# code and generator-specific files. Generators create a pipeline, starting from base input sources and mapping them to the output they wish to produce. The more exposed, properly equatable states exist, the earlier the compiler will be able to cut off changes and reuse the same output.”

Figure 1 — Source Generator dataflow, Microsoft

Simply put, source generators in .NET are library projects that you can add to a solution or include in existing NuGet packages. They are meant to be utilized only during the build process to add new code to a project.

[Read more about common source generator use cases here].

What Are Source Generators Not Meant to Do

Microsoft calls out two main concepts as areas where generators are not meant to be used. The first area is adding language features. Microsoft states: “Source generators are not designed to replace new language features: for instance, one could imagine records being implemented as a source generator that converts the specified syntax to a compilable C# representation. We explicitly consider this to be an anti-pattern; the language will continue to evolve and add new features, and we don’t expect source generators to be a way to enable this. Doing so would create new ‘dialects’ of C# that are incompatible with the compiler without generators.”

In this regard, I agree with the team that allowing any .NET developer to start adding new features to the language opens up the possibility of competing features, confusing requirements, and incompatibility with the .NET compiler; which will only serve to confuse and push developers away from source generators altogether.

The second is in code modification; the Microsoft documentation also states, “There are many post-processing tasks that users perform on their assemblies today, which here we define broadly as ‘code rewriting’. These include, but are not limited to:

• Optimization
• Logging injection
• IL Weaving
• Call site re-writing

While these techniques have many valuable use cases, they do not fit into the idea of source generation. They are, by definition, code altering operations which are explicitly ruled out by the source generator’s proposal.”

While technically accurate, this feels more like a semantic line in the sand for the team not wanting a “generator” to perform replacement and not a language-breaking functionality to have access to. With that said, I will show a workaround for code rewriting that I’ve used recently if that is part of your goal for using a source generator.

A source generator is also not an Analyzer. While often used together and sharing many of the exact same requirements to utilize one in a project, a generator’s job is to produce code and an analyzer’s job is to produce warnings or errors based on various rules such as code formatting or, as we will see in source generators, to block access to specific functions/code bases that the analyzer’s author deemed unwelcome.

The Primary Type of Source Generator in Modern .NET

At the time of writing this (September 2024), the .NET team has decided to deprecate source generators implementing “ISourceGenerator” in favor of incremental generators. This change will be enforced, seemingly blocking access to older “ISourceGenerator” APIs with versions of the Roslyn API after version 4.10.0 / .NET 9. (Old Generator Deprecated). In light of that, this blog post series will only cover “IncrementalGenerator” usage.

What Is an Incremental Source Generator?

An incremental generator is a source generator that performs its evaluation and execution on items only after they pass some filtering requirements, significantly increasing performance.

Typically, source generators try to execute during design time and compile time. While nice, this incurs an execution of any classes marked as a source generator every time something changes in the project (i.e., delete a line of code, add a line of code, make a new file, etc.). As you can imagine, having something running every time you type is not ideal for performance; thus, Microsoft created these incremental generators to help solve that performance problem.

Adding an Incremental Source Generator to Your Project

Source generators must target .NET standard 2.0. This allows them to be used in .NET framework 4.6+ or .NET core 5+ projects or other .NET standard 2.0+ projects. By the end of this section, we will have a solution containing three projects.

• A .NET standard 2.0 library (Source Generator)
• A .NET standard 2.0 library (A shared library for the generator and consumers)
• A .NET 8 web API project (Main project)

You can use the dotnet command in a terminal or your IDE of choice to create these projects. I will use the dotnet tool since it is IDE/platform agnostic. The following commands will produce the required projects.

1. dotnet new sln -n IncrementalSourceGenPractice
2. dotnet new webapi -n WebProject — project .\IncrementalSourceGenPractice.sln
3. dotnet new classlib -f netstandard2.0 — langVersion 12 -n SourceGenerator — project .\IncrementalSourceGenPractice.sln
4. dotnet new classlib -f netstandard2.0 — langVersion 12 -n SourceGenerator.SharedLibrary — project .\IncrementalSourceGenPractice.sln
5. dotnet sln .\IncrementalSourceGenPractice.sln add .\SourceGenerator.SharedLibrary\SourceGenerator.SharedLibrary.csproj .\SourceGenerator\SourceGenerator.csproj .\WebProject\WebProject.csproj

Before creating the source generator, adding a few Nuget packages and changes to the .csproj files are required. Open the SourceGenerator.csproj file and ensure it matches the following content.

https://medium.com/media/dd367dc0ae1158c23a5b82cf17ba07f5/href

The version numbers of the package references will likely be different, which is fine as long as they are valid for the .NET standard 2.0 target.

The three configuration settings added are the following

1. <EnforceExtendedAnalyzerRules>true</EnforceExtendedAnalyzerRules>

• Ensures the generator is using the recommended rules created by the .NET team

2. <IsRoslynComponent>true</IsRoslynComponent>

• Enables the project to act as a generator and work with the Roslyn compiler, making debugging of the generator possible

3. <IncludeBuildOutput>false</IncludeBuildOutput>

• This prevents the project build from being included in output, which is ideal since the generator is meant to be compile-time only

The other odd configuration in this .csproj file is the OutputItemType=”Analyzer” added to the project reference for the shared library. Even though the shared library is not an analyzer, this is required so the generator can access it during generation.

The final bit of configuration required is for the webproject.csproj file.

Add the following lines to the project.

<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>.\GeneratedFiles</CompilerGeneratedFilesOutputPath>

• These two options allow the source generator files to be written to the filesystem and set a custom path to write them to vs. using the default path.

Lastly, add the following item group also to the webproject.csproj file.

<ItemGroup>
<ProjectReference Include="..\SourceGenerator.SharedLibrary\SourceGenerator.SharedLibrary.csproj" />
<ProjectReference Include="..\SourceGenerator\SourceGenerator.csproj" ReferenceOutputAssembly="false" OutputItemType="Analyzer" />
</ItemGroup>

• When referencing the source generator, we do not need the output assembly again because it is not required after compile time.

Adding a Relevant Target for Generation

In this first part, we will generate something relatively simple; however, later posts go deeper into using source generators and we will create a small AOP framework to achieve the goal outlined at the start of this blog.

Open the WebProject and add a new class called Calculator.cs with the following source.

https://medium.com/media/30ebc82f45a40769bd16d812efb22e7a/href

We will then generate functions for this class to add, subtract, multiply, and divide. We must mark the class as partial to stick with the intended functionality of only adding content to existing classes. This indicates that more of the class’s source code may be in a different file.

Starting on the Incremental Source Generator

Congratulations; we finally made it through the required setup.

Finally, with that configuration done, we can start writing the source generator. In the SourceGenerator project, add a class named CalculatorGenerator with the following content.

https://medium.com/media/10d010241aa9280c31d8b38892d66486/href

This gives the bare-bones starting point. To be a valid Incremental source generator, the class must inherit from `IIncrementalGenerator` and be decorated with the [Generator] attribute. The interface requires our generator to implement only the’ Initialize’ function.

The Providers

The IncrementalGeneratorInitializationContext argument it provides in the Initialize method will give access to the underlying source.

The context object does this via several different “providers.”

Different Provides for Accessing Various Contexts

• CompilationProvider -> Can access data relevant to the entire compilation (assemblies, all source files, various solution-wide options, and configs )
• SyntaxProvider -> Access to syntax trees to analyze, transform, and select nodes for future work (Most commonly accessed)
• ParseOptionProvider -> Gives access to various bits of info about the code being parsed, such as language, whether it’s regular code files, script files, custom preprocessor names, etc.
• AdditionalTextsProvider -> Additional texts are any non-source files you might want to access, such as a JSON file with various user-defined properties
• MetadataReferencesProvider -> Allows getting references to various things like assemblies without getting the whole assembly item directly
• AnalyzerConfigOptionsProvider -> If a source file has additional analyzer rules applied to it, this can access them

The ones we care about are CompilationProvider and SyntaxProvider.

Access the context.SyntaxProvider.CreateSyntaxProvider() method call.

This method takes two arguments. The first is called thepredicate, a super lightweight filter that reduces everything in the codebase to only the items we care about. The second is called thetransform, which ingests what we care about from the filter and makes any additional changes, property access, additional filtering, etc., as desired before returning the objects we want to work with later.

An example of using this syntaxProvider method is as follows.

The names of the arguments (predicate, transform) do not have to be supplied. I included them to make it easier to understand which is which.

https://medium.com/media/b0ad897bf84ad2327a80bf198b4c2f86/href

The Predicate

The predicate code’s first argument is a SyntaxNode , and the second is a CancellationToken. The token allows any asynchronous tasking performed in this method to be gracefully stopped if needed. In this example, it is unnecessary, so we will focus on the SyntaxNode.

(SyntaxNode node, _) =>
{
return node is ClassDeclarationSyntax classDeclaration &&
classDeclaration.Identifier.ToString() == “Calculator”;
}

The preceding code can seem daunting initially, as you are quickly bombarded with terms not typically seen by C# developers (e.g., SyntaxNode, ClassDeclerationSyntax, identifier, etc.). If you are anything like me, you are wondering what they mean, what they are used for, and why you need to use them.

Source generators work alongside / utilize the Roslyn compiler. Roslyn is a set of compilers and code analysis APIs. Roslyn understands your code and projects by breaking down almost everything into SyntaxNodes and SyntaxTokens.

Some examples of syntax tokens include access modifiers like public or private, modifiers like static, abstract, and partial. Names of items like a class name, namespace, method name, etc.

Tokens also include grammar items in the language, like semicolons, brackets, etc.

Example of a SyntaxToken Item

Examples of syntax nodes include class declarations, method declarations, bodies of methods, and individual lines of code, including assignments, expressions, and using statements.

Example of a Syntax Node in this case a Class Declaration Syntax Node

This programmatic code breakdown is then used to analyze code, write new classes, modify methods, etc. While this can feel daunting, something to remember is that syntax is ultimately still text, and syntax objects can be cast into a string if required. This is precisely what we do in the predicate to convert this SyntaxToken into a string with the .ToString() method to compare it to our target name.

There are various syntax nodes and token types, which I plan to break down and provide examples of in later posts in the series.

In summary, the predicate says if this piece of code represents declaring a class like public partial class Calculator, then check if its identifier (i.e., class name) is “Calculator,” and if so, pass it to the transform. This way, when the generator sees a node like public static void Main(), it knows to skip it.

The Transform transform: (GeneratorSyntaxContext ctx, _) =>
{
var classDeclaration = (ClassDeclarationSyntax)ctx.Node;
return classDeclaration;
}

The transform takes in the item that passed the filter and a cancellation token again to help cancel it if needed. The GeneratorSyntaxContext item is basically the node and some extra metadata. We then cast the context node item to a ClassDeclarationSyntax. This is required because even though the filter only passed us nodes of that type, the SyntaxContext does not understand that; however, we can cast it and safely know we are getting what we expect.

The transform is where we could extract members of the class, bodies of methods, etc.; whatever item we want to work on. In this example, we want to work on a class, so we get the item as a ClassDeclarationSyntax.

Finally, we add a where statement to filter out any null items that may have made it through. This is optional, but ensuring we aren’t getting some weird invalid item does not hurt.

The CreateSyntaxProvider returns an IncrementalValuesProvider<T> where T is whatever item type we are trying to return from the method call.

An `IncrementalValuesProvider` is a fancy word for the object holding our returned items. There is also an IncrementalValueProvider<T>, which is similar but is meant to have one object instead.

For example, our code’s ValuesProvider contains class declarations from the ClassDeclarationSyntax type.

This then leaves us with an initialization method like this:

https://medium.com/media/c00809482473b3d19c0697bf6cb5a90d/href

The last central part of using a source generator is telling it what to do with the items we got back. Go ahead and add the context. RegisterSourceOutput() line to your project. This tells the generator what to do with the returned items. Next, we will go over the content of this Execute method.

The Execute Method

Alright, so we have our target type; we are filtering out everything we don’t care about, so let’s send it to the execute method and generate our source code.

The execute method is typically defined as follows:

public void Execute(ClassDeclarationSyntax calculatorClass, SourceProductionContext context)
{
//Code to perform work on the calculator class
}

The first argument will vary depending on the work you are trying to perform and the method can be modified to take extra arguments as needed. The SourceProductionContext object gives us essential information about the project/solution and enables us to add code to the compilation to include it in the final build.

Since our goal is to generate some simple calculator functions, we will first check all the members of the class we are working on to see if they already have a method with the same name so we don’t accidentally override an existing version. Next, we will gather some metadata, like the namespace, any modifiers, and any using statements, to ensure the code compiles correctly. Lastly, we will insert the code we want into the source file and save it to the compilation.

https://medium.com/media/f854aa10ea2e8c34783650948971019f/href

So the final generator code should look like the following:

https://medium.com/media/448789dddc2b13f03024903d2085d840/href

Alright, all the pieces are in place. Let’s build the solution and check out the generated code.

Example Error Messages When Source Generation Fails

Well, that’s not what we hoped for; however, as with many development projects, errors are bound to happen. Don’t panic yet; that is intended to show off some important things when working with source generators. First, source generators will only present a warning when they fail to generate code, so watch for warning messages like this when compiling the code.

Warning CS8785 : Generator ‘CalculatorGenerator’ failed to generate source. It will not contribute to the output and compilation errors may occur as a result. Exception was of type ‘NullReferenceException’ with message ‘Object reference not set to an instance of an object.’.

Second, source generators execute at compile time, making capturing extra context from the exception challenging as you might typically do with a try-catch where you can print info to the console.

If you try something like the following, you will notice no additional information is sent to the console.

public void Execute(ClassDeclarationSyntax calculatorClass, SourceProductionContext context)
{
Try
{
// code from before
}
catch(Exception ex)
{
Console.WriteLine(ex);
}
}

OK, no problem. Instead, Let’s save the message to a file in the catch statement.

File API Blocked in Source Generators

OK, maybe not. If we can’t log to a file in the generator and we can’t log to the console, how will we get the details we need to figure out what is going wrong?

Logging in Source Generators

This brings us to logging in source generators, which I wanted to include in this first part because it is by far the most accessible means of troubleshooting issues when using source generators.

To enable logging in the source generator, open the shared library we made at the start. It should have a single class named class1. Rename that to GeneratorLogging. While the File API is blocked inside the source generator itself, adding that functionality to a secondary library and having it write the content in a file for you is possible.

A simple logging class would be something like the following

https://medium.com/media/d2ee7383cf66da2e79d4042bf2ab6d95/href

There are a few key parts I will quickly explain.

• The lock object -> This ensures that only one instance of the log message call runs simultaneously. This way, the source generators do not step on each other while trying to access the same file. Even with just one source generator, this can still happen because it checks multiple classes simultaneously.
• The log message method -> This method will create the file at the provided path if it does exist. Then, so long as the log level is equal to or higher than the set level, it will log the message to the file. It will also add a small header and footer to messages set higher than info to better showcase errors.

Fixing the Example Code

Using the logging class is very straightforward; if you haven’t already, ensure the shared library is added as a dependency of the generator project so it can access it. So, let’s add some logging calls to our current code and see what the log shows.

https://medium.com/media/385cf2859d0c6be2ccde8d9ce079a1f7/href

If needed, perform dotnet clean to clean up any previous logs or generated files. Then, build the solution and check the log file.

The log then will contain output like the following:

[+] Generated Log File
[+] This file contains log messages from the source generator
Logging started at 2024–09–14 19:42:12.287
[+] Found 2 members in the Calculator class
[+] Checked if methods exist in Calculator class
[+] Added using statements to generated class

[Error start]
[-] Exception occurred in generator: System.NullReferenceException: Object reference not set to an instance of an object.
at SourceGenerator.CalculatorGenerator.Execute(ClassDeclarationSyntax calculatorClass, SourceProductionContext context)
[Error end]

From this log output, we can see the generator is running into this Null Reference Exception right after the using statement code, so let’s take a more in-depth look at that.

GeneratorLogging.LogMessage(“[+] Added using statements to generated class”);
calcGeneratedClassBuilder.AppendLine();

SyntaxNode calcClassNamespace = calculatorClass.Parent;

while (calcClassNamespace is not NamespaceDeclarationSyntax)
{
calcClassNamespace = calcClassNamespace.Parent;
}
GeneratorLogging.LogMessage($"[+] Found namespace for Calculator class {calcClassNamespace?.Name}", LoggingLevel.Info);

Here, we see the calcClassNamespace enumerates through the parents of the class object until it finds something. However, we did not add any null checks to ensure we had a namespace before continuing. Let’s modify this section of code to handle the nulls and perform a check against the nodes ancestors as well.

GeneratorLogging.LogMessage(“[+] Added using statements to generated class”);

calcGeneratedClassBuilder.AppendLine();

BaseNamespaceDeclarationSyntax? calcClassNamespace = calculatorClass.DescendantNodes().OfType<NamespaceDeclarationSyntax>().FirstOrDefault() ??
(BaseNamespaceDeclarationSyntax?)calculatorClass.DescendantNodes().OfType<FileScopedNamespaceDeclarationSyntax>().FirstOrDefault();

calcClassNamespace ??= calculatorClass.Ancestors().OfType<NamespaceDeclarationSyntax>().FirstOrDefault();
calcClassNamespace ??= calculatorClass.Ancestors().OfType<FileScopedNamespaceDeclarationSyntax>().FirstOrDefault();

if(calcClassNamespace is null)
{
GeneratorLogging.LogMessage(“[-] Could not find namespace for Calculator class”, LoggingLevel.Error);
}
GeneratorLogging.LogMessage($”[+] Found namespace for Calculator class {calcClassNamespace?.Name}”);

This updated version will now search through all of the child and ancestor nodes to see if the previous checks were null and update them as needed. If they are still null, we should get a log entry to keep troubleshooting issues.

This then gives us a final working source generator of:

https://medium.com/media/50b108415f0110617e43ced6881796e5/href

We can test this by modifying the WebApi project we created at the start.

Open the WebApi program.cs file and modify it to look like this:

https://medium.com/media/673f0284e8b3088d36d3531400658f7b/href

When we run this project and send a get request to the / URL, we will get back a message with the results from the source-generated methods.

API Call Showing the Generated Code Compiled and Executed Correctly Conclusion for Part 1

I would like to cover many other capabilities of source generators in future parts that help showcase the real power behind them. So, if you enjoyed this first installment, stick around for more in-depth looks at C# source generators.

Dotnet Source Generators in 2024 Part 1: Getting Started was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Dotnet Source Generators in 2024 Part 1: Getting Started appeared first on Security Boulevard.

Pittsburgh, PA, Oct. 1, 2024 — ForAllSecure, the world’s most advanced application security testing company, today announced it is changing its corporate name to Mayhem Security (“Mayhem”), signaling a new era of growth and opportunity aligned with its award-winning … (more…)

The post News alert: Introducing Mayhem Security — ForAllSecure unveils name change, fresh focus first appeared on The Last Watchdog.

The post News alert: Introducing Mayhem Security — ForAllSecure unveils name change, fresh focus appeared first on Security Boulevard.

via the comic humor & dry wit of Randall Munroe, creator of XKCD

Permalink

The post Randall Munroe’s XKCD ‘Beamsplitters’ appeared first on Security Boulevard.

In a groundbreaking move, the House Administration Committee, along with the Chief Administrative Officer (CAO) for the House of Representatives, have introduced a comprehensive policy aimed at governing the use of artificial intelligence (AI) within the lower chamber. This policy is a significant milestone designed to foster the secure and effective deployment of AI technologies while addressing cybersecurity risks. The policy, which took effect on August 28, presents a structured approach to assessing and prioritizing AI tools, enabling all House personnel to contribute ideas and technologies. 

The post Breaking Down the House’s New Artificial Intelligence Policy appeared first on Security Boulevard.

APIs are crucial in our digital world, but they also introduce new vulnerabilities. Attackers often exploit these vulnerabilities by concealing malicious payloads within encrypted traffic, rendering them undetectable to traditional security tools. As we observe Cybersecurity Awareness Month, it's important to emphasize the significance of advanced solutions that can detect hidden threats.

eBPF: Illuminating the Dark Corners of API Traffic

eBPF (extended Berkeley Packet Filter) is a powerful method for inspecting network traffic, including encrypted traffic. It works within the Linux kernel to analyze API calls at a detailed level, identifying and blocking malicious activity with speed and efficiency. eBPF provides significant advantages in detecting and responding to hidden API threats without complex decryption processes.

Why eBPF Matters for API Security

eBPF offers several key advantages for API security:

• Deep API Visibility: eBPF offers unparalleled visibility into encrypted API traffic, enabling security teams to detect and respond to hidden threats.
• Performance and Scalability: eBPF is designed to be highly efficient and scalable, making it ideal for analyzing large volumes of API traffic without impacting system performance.
• Flexibility and Extensibility: eBPF is a flexible framework that can be extended to support a wide range of API security use cases, including threat detection and prevention, compliance monitoring, and incident response.

Salt Security and eBPF: A Powerful Combination

Salt Security, a leader in API security, has utilized eBPF to gain exceptional visibility into encrypted API traffic. By leveraging eBPF, Salt Security can:

• Inspect Encrypted Traffic: eBPF enables Salt Security to inspect encrypted API traffic at the kernel level, after ssl termination. This capability allows Salt Security to detect suspicious patterns and anomalies within encrypted payloads, providing essential protection against attacks that would otherwise be unnoticed.
• Increased Visibility: eBPF gives Salt Security detailed insight into API calls, including request and response headers, payloads, and metadata. This information allows Salt Security to create thorough API behavioral profiles, pinpoint subtle deviations from normal patterns, and accurately identify potential threats.

The Future of API Security with eBPF

The evolving nature of API attacks highlights the increasing importance of eBPF in API security. With its ability to offer comprehensive visibility, high performance, and flexibility, eBPF enables security teams to proactively protect their APIs from advanced threats, especially when combined with next-generation security solutions like Salt Security. Salt Security's incorporation of eBPF support demonstrates the potential for this technology to revolutionize how organizations approach API security. eBPF will be a critical component of our future API protection capabilities, allowing us to achieve comprehensive security across all layers by integrating it with our existing AI-powered engine. This integration will facilitate the identification and mitigation of threats at both the kernel and application levels, providing unparalleled protection against sophisticated attacks.

If you want to learn more about Salt and how we can help you on your API Security journey through discovery, posture management, and run-time threat protection, please contact us, schedule a demo, or check out our website.

The post Seeing the Unseen: Salt Security and eBPF appeared first on Security Boulevard.

Modern businesses are increasingly reliant on APIs. They are the building blocks facilitating data exchange and communication between disparate systems. Because of their prevalence and importance, they are also under attack by actors exploiting vulnerabilities and misconfigurations.  Unauthorized access, data exposure, injection attacks, broken authentication, DoS attacks, shadow or unmanaged APIs, insecure API dependencies, and [...]

The post API Gateways and API Protection: What’s the Difference? appeared first on Wallarm.

The post API Gateways and API Protection: What’s the Difference? appeared first on Security Boulevard.

Authors/Presenters:Yiluo Wei, Dennis Trautwein, Yiannis Psaras, Ignacio Castro, Will Scott, Aravindh Raman, Gareth Tyson

Our sincere thanks to USENIX, and the Presenters & Authors for publishing their superb 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI '24) content, placing the organizations enduring commitment to Open Access front and center. Originating from the conference’s events situated at the Hyatt Regency Santa Clara; and via the organizations YouTube channel.

Permalink

The post USENIX NSDI ’24 – The Eternal Tussle: Exploring the Role of Centralization in IPFS appeared first on Security Boulevard.

As we enter October, we once again recognize national Cybersecurity Awareness Month, a pivotal initiative to raise awareness about the importance of securing our digital world.

The post Cybersecurity Awareness Month: Building a safer digital world together appeared first on Security Boulevard.