Like many successful development teams, if you use Jira epics to track new features from design to deployment, Seezo can help you automatically incorporate Security Requirements into your SDLC, without any additional effort from your developers.  

Providing developers early security feedback

Modern companies deploy dozens of new features to production every week. These features are often tracked as Jira epics.  While some features have no security impact (E.g.: a CSS change), some changes (e.g.: a new role added) can have a significant security impact. The current tooling in the AppSec world (SAST, DAST, Container scanning, etc.) only provides feedback to developers once the security defect is introduced. This means, developers do not have access to contextual security requirements and all vulnerabilities are discovered after introducing them. To solve this, security teams take one of 2 approaches: 

• Ignore & accept risk: Point developers to a large, static security requirements artifact (SharePoint site, wiki, etc.). While such artifacts contain a wealth of information, they do not provide specific guidelines for the features being developed.

• Manual security review: The developers are expected to answer a few questions, which will help determine if a feature is “security significant”. If it is, the Security team manually reviews the feature. At the end of the assessment, the Security team provides requirements in the form of security tickets, which are tracked as child issues in the main epic.

Pitfalls of the "manual review" approach

Manual reviews are hard to scale. If hundreds of epics are written each quarter, the Security team will not have the capacity to review all of them thoroughly.

1. Manual assessments often lead to inconsistent results. This can happen because of two specific reasons: 

   1. Developers erroneously mark an epic as not security significant. This can happen due to lack of awareness, manual error (e.g.: “forgot to check the box”), or as a way to avoid scrutiny. 

   2. This also means, only senior security team members can carry out these assessments, further hampering coverage.

Seezo can solve this 

While the current solution works well, it requires significant manual effort from the Security team. It adds timeline pressure to Security and engineering teams (e.g.: developers cannot start building until the security requirements are in). Seezo can help solve this. Once integrated with your Jira pipeline, Seezo will:

1. Analyze the details associated with the epic (diagrams, tech information, etc.). Seezo uses a combination of Multi-modal RAG (scans images, tables, flowcharts, and text), prompt engineering ( to look for relevant security controls), and decision trees (to reduce hallucination) to achieve these results.

2. For each assessment, Seezo will generate the following:

   • Security summary: This helps the Security team understand key aspects of the new feature from a security perspective. (e.g.: How does the application handle users?) 

   • Security requirements: Actionable requirements to the engineering team (e.g.: Make sure the PII collected in the form is not logged. Use utils.logger(PII=off) to make this happen). 

   • Open questions: This section lists questions that could not be answered due to a lack of information in the ticket. This typically happens when the document provided is incomplete. These questions will be published as comments on the epic. 

3.  Create security requirements as child tickets: All the above information is visible to your Security team on the Seezo portal. Once the Security Engineer reviews the information, they can automatically push the requirements as a child ticket and the open questions as a comment on the epic.