Skip to main content

Quickstart

This is the shortest path from your first sign-in to a version ready for publishing.

Before you start​

You'll need:

  • access to an active RuleForge organization;
  • a role that lets you create or edit projects.

If you don't have that yet, see First access.

Step by step​

1. Create a project​

In Projects, click New project, give it a name and short description (for example, "SSH detections — SOC team").

2. Open the editor​

Inside the project, open the Editor. It's your lab for writing and testing content.

3. Write or import rules​

In the editor you adjust:

  • decoders (how the log is parsed);
  • rules (what raises an alert);
  • the log format you'll test against;
  • a sample event to validate with.

If your team already has content in a Git repository, you can import it directly instead of starting from scratch.

4. Validate​

Click Validate. RuleForge flags structural errors, warnings, suggestions, and calculates a quality score.

5. Test with a real event​

Use Log test to see what happens when your event flows through the content:

  • which decoder was applied;
  • which rule fired;
  • which fields were extracted;
  • the full processing trace.

6. Save regression cases​

Important scenarios become test cases. They run again every time the content changes — so you make sure a change didn't break what was already working.

7. Save a workspace​

The workspace preserves the current state. Use it when you want to pause without losing context, or when you want to save a draft to review later.

8. Open a review​

When the content is ready for approval, open a review and request analysis from the designated reviewer.

9. Create a version and publish​

After approval, create a version and click Publish. If any quality criteria aren't met yet, the screen points out exactly what's missing.

What you'll have at the end​

  • a structured project;
  • validated content;
  • saved regression cases;
  • review history;
  • a version ready or published.

What can block publishing​

  • validation errors;
  • quality score below the minimum;
  • failing regression;
  • unapproved review, when the policy requires it.