Some failed controls are not showing up even though Kubescape result contains them

[amirmalka]

Root cause: A bug in getStartIndexAcc fails to detect fixPath location (returns -1), and as a result, failed controls are not added to the report collection (see https://github.com/kubescape/vscode-kubescape/blob/master/src/Kubescape/scan.ts#L27)

Steps to reproduce:

1. Scan the following YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: adservice
spec:
  selector:
    matchLabels:
      app: adservice
  template:
    metadata:
      labels:
        app: adservice
    spec:
      serviceAccountName: default
      terminationGracePeriodSeconds: 5
      containers:
      - name: server
        image: adservice
        securityContext:
          runAsRoot: true        
        ports:
        - containerPort: 9555
        env:
        - name: PORT
          value: "9555"
        # - name: DISABLE_STATS
        #   value: "1"
        # - name: DISABLE_TRACING
        #   value: "1"
        #- name: JAEGER_SERVICE_ADDR
        #  value: "jaeger-collector:14268"
        resources:
          requests:
            cpu: 200m
            memory: 180Mi
          limits:
            cpu: 300m
            memory: 300Mi
        readinessProbe:
          initialDelaySeconds: 20
          periodSeconds: 15
          exec:
            command: ["/bin/grpc_health_probe", "-addr=:9555"]
        livenessProbe:
          initialDelaySeconds: 20
          periodSeconds: 15
          exec:
            command: ["/bin/grpc_health_probe", "-addr=:9555"]
---
apiVersion: v1
kind: Service
metadata:
  name: adservice
spec:
  type: ClusterIP
  selector:
    app: adservice
  ports:
  - name: grpc
    port: 9555
    targetPort: 9555

2. Line runAsRoot: true fails due to C-0013
3. Failed control is not showing up in the extension

A fix should be made in https://github.com/kubescape/node-yamlparse so that fixedPath is parsed correctly

[amirmalka]

A different approach for fixing this issue is to use the SARIF format which already implements the yaml parsing.

[angad-singhh]

Hey @amirmalka, I'm currently working on this issue. I will update the progress soon. Hope to contribute more.

[angad-singhh]

Hey @amirmalka , I went through the yamlParse process and how we are highlighting and scanning in VS Code.

The issue seems to be in the config YAML file. There it is written runAsRoot: value in securityContext. It should be runAsNonRoot: value

Now, for why it doesn't show on problems tab is, The fix path obtained through controls in scan results , is spec.template.spec.containers[0].securityContext.runAsNonRoot which mean when it is broken down into steps and we find startIndex, it particularly searches for runAsNonRoot in all lines, as no found is matched it returns -1.

I have tested with other scenario, the VS Code extension works fine. Please let me know, if you need any change in code.