Findings best practices: Closed-loop security risk inspection - STAROps

Business scenario

Enterprise security teams need to regularly inspect the public exposure of cloud resources. For example, they need to check whether security groups allow high-risk ports such as SSH (22) and RDP (3389) from 0.0.0.0/0. Traditional inspection methods have the following pain points:

Problems are tracked in manual ledgers: An inspection report is only a snapshot. Whether a problem has been handled and how far handling has progressed must be manually recorded and followed up.
Duplicate problems are repeatedly reported: The same security group rule problem appears in every inspection report, without being recognized as the same existing problem.
Fix effectiveness cannot be verified: There is no automated way to verify whether a security group rule was changed or changed correctly, and "no alert observed" is often mistaken for "problem resolved".
Problem recurrence goes unnoticed: When a resolved problem is reintroduced, there is no mechanism to associate it with historical handling records.

With STAROps Findings, a Digital Employee automatically consolidates risks found during inspections into Findings, deduplicates them, tracks handling progress, verifies fixes, and reopens the original Finding upon recurrence, enabling closed-loop security risk management.

Solution architecture

The complete closed loop in this practice involves the following core stages:

Scheduled inspection: Create a long-running task (Mission) that is triggered on a schedule. The Digital Employee automatically checks security group rules as scheduled.
Finding generation: The Digital Employee consolidates the risks found during inspection into Findings. If the same security group rule exposes multiple ECS instances, the problems are aggregated into one Finding anchored to the security group. Before creating a Finding, the system automatically checks its similarity to historical Findings to prevent duplicate reports.
Viewing and confirmation: O&M personnel view the Finding details, evidence, and impact scope in the console. If they doubt the conclusion, they can initiate "Re-confirm" for the Digital Employee to re-examine it.
Handling execution: A Finding comes with handling tasks (Tasks) and verification conditions. Restricting security group rules is a high-risk operation and enters the human-in-the-loop (HIL) process by default. After one-click confirmation through an IM tool such as DingTalk, the Digital Employee can execute it.
Verification and closure: When the next inspection round covers the original inspection scope and no longer finds the risk, the Finding is automatically closed.
Reopening upon recurrence: When a closed problem occurs again, the original Finding is reopened and continues its history, instead of creating a new problem.

Environment check

Before you begin, make sure that the following environment is ready:

Check item	How to confirm
A Digital Employee has been created	In the STAROps console, confirm that the target Digital Employee is in a normal state.
Cloud resource data has been connected to the workspace	On the workspace details page, confirm that configuration data for cloud resources such as security groups and ECS instances has been connected.
The Digital Employee has the required permissions	The RAM role associated with the Digital Employee must have read permissions on security group rules. To automatically perform restriction operations, it must also have the corresponding write permissions.
A notification channel has been configured	To confirm high-risk operations through IM, configure a notification channel such as DingTalk in advance.

Implementation steps

Step 1: Create a long-running security inspection task

Log on to the STAROps console.
In the left-side navigation pane, click Long-running Tasks to go to the long-running task management page.
In the upper-right corner of the page, click + Create Long-running Task.
In the dialog box, select a Digital Employee and a model.
Describe the inspection objective in natural language. Example:
```
I need to create a scheduled security inspection task that runs every day at 9:00 AM.
Inspection scope: Inbound rules of all security groups in the current workspace.
Key checks:
1. Whether high-risk management ports such as 22 and 3389 are open to 0.0.0.0/0.
2. Which security groups and ECS instances are affected.
Output requirements: Consolidate discovered risks into Findings. Aggregate the exposure of
multiple ECS instances caused by the same security group rule into one Finding, and provide
handling suggestions and verification conditions.
```
After you enter the objective, the Digital Employee aligns on intent, confirms the inspection frequency, scope, and output format, and automatically generates an execution blueprint (Blueprint). After you confirm the blueprint, the long-running task starts.

Note
The more specific the objective description, the more accurate the generated execution blueprint. We recommend that you clearly specify the inspection frequency, inspection scope, ports of interest, and aggregation granularity.

Step 2: View problems found during the inspection

After the inspection is complete, view the generated Findings from any of the following entry points:

View all Findings under the current account on the Problem List page of the console.
View the Findings generated by this inspection task on the long-running task details page.
Filter by Digital Employee to focus on Findings from a specific execution entity.

Click the target Finding to go to its details page and view its complete information. In the preceding scenario, a typical Finding contains:

Title             Security group exposes SSH to the public internet
Category          Security risk        Severity    High
Confidence        0.95
Summary           The same security group rule exposes port 22 on multiple ECS instances.

Affected objects  Security group sg-xxx (anchored object)
                  10 ECS instances, including i-xxx1 and i-xxx2 (affected objects)

Evidence          Snapshot of inbound security group rule: TCP 22/22, source 0.0.0.0/0

Handling task     Restrict the inbound security group rule for public SSH access
                  Risk level: High (manual confirmation required before execution)
                  Verification condition: The security group no longer allows 0.0.0.0/0:22

State             Open    First discovered: 06-10 09:00    Occurrence count: 1

Step 3: Confirm the problem conclusion (optional)

If you doubt the Finding judgment, you can:

Click Re-confirm. The system automatically initiates a conversation for the Digital Employee to re-examine whether the problem is reasonable. For example, although a security group allows port 22, all associated instances may be stopped, so the Digital Employee reassesses the actual risk.
Provide positive or negative feedback on the Finding. For negative feedback, you can specify a reason, such as "The affected objects were identified incorrectly", to help the Digital Employee continuously improve its judgment quality.
For problems that require focused follow-up, use operations such as pinning and bookmarking.

Step 4: Confirm and execute handling

On the Finding details page, view the handling solution and risk prompt for the handling task.
Because restricting security group rules is a high-risk operation, a confirmation prompt appears before execution. Check the impact scope, including the 10 associated ECS instances and channels that depend on SSH for O&M.
After confirming that the information is correct, complete human-in-the-loop (HIL) confirmation in any of the following ways:
- Confirm execution directly in the console.
- Click Confirm in an IM notification such as a DingTalk notification, which can be sent to an individual or group.
- Integrate with an enterprise approval system through OpenAPI to complete confirmation.
The Digital Employee performs the handling action by restricting the allowed source for port 22 to an office network CIDR block or bastion host security group. The entire execution process is observable.

Important
By default, high-risk operations are executed only after manual confirmation. Make sure that the handling solution preserves a legitimate O&M access channel to prevent loss of access caused by directly closing port 22.

Step 5: Verify the fix and automatically close the Finding

When the next scheduled inspection runs, the Digital Employee checks the security group rules in the original scope again:

If the verification condition "The security group no longer allows 0.0.0.0/0:22" is met, the Finding is automatically closed with the closure type "Resolved", while complete handling and verification records are retained.
If this inspection round does not cover the original inspection scope, for example, because the data source is temporarily unavailable, the Finding is not closed, preventing "not inspected" from being mistaken for "resolved".

You can also review the evidence and manually close the Finding on the details page at any time.

Step 6: Handle problem recurrence

Suppose that one month later, someone changes the security group rule back to allow access from 0.0.0.0/0. When the next inspection finds the risk:

The system recognizes that it is the same problem as the closed Finding, automatically reopens the original Finding, and increments the occurrence count.
You can trace the complete history of the problem, including when it was first discovered, the handling solution at that time, the verification records, and evidence of this recurrence, to quickly determine whether the recurrence was caused by a configuration rollback or a new change.

Results

With this practice, security risk inspection is upgraded from "producing reports" to "managing closed loops":

Deduplication and noise reduction: Thirty inspections of the same problem correspond to only one Finding, and the occurrence count is automatically accumulated.
Clear accountability: Each handling task has a clearly defined owner and verification condition, and handling progress is trackable.
Secure and controllable: Manual confirmation safeguards high-risk operations, and the entire execution process is recorded and auditable.
Recurrence awareness: When a problem recurs, it is automatically reopened and associated with its complete history.

Extended scenarios

The same closed-loop model applies to more inspection scenarios:

Scenario	Finding aggregation method
Multiple disks are about to fill up	Split by disk or mount point for independent handling and verification.
Multiple Pods have the same crash signature	Aggregate them into one Finding anchored to the service they belong to.
SSL certificate expiration check	Aggregate by certificate or domain name. The handling task is to update the certificate and verify that it takes effect.
Diagnostic gaps such as unconnected data and insufficient permissions	Generate a gap-type Finding whose handling task specifies the data or permissions that must be added.