Coordinate security remediation across every Jira team.
Create remediation work across affected teams, see who's finished, identify stale work, and automatically follow up until the rollout is complete.
Jira tracks the tickets. Armada tracks the rollout.
- PaymentsPAY-421Done
- SearchSRCH-81Blocked
- IdentityID-231In progress
- CheckoutCHK-77Done
- NotificationsNTF-19Done
- BillingBIL-302Done
67% complete4 of 6 teams done
Search needs attention. Blocked on a base image, no update in 6 days.
Creating the tickets is easy. Getting every team to finish is the hard part.
A critical vulnerability affects 40 services. Filing 40 Jira issues takes an afternoon. Then the real work starts, and most of it happens outside Jira: in a spreadsheet, in chat threads, and in the weekly status meeting.
Ownership
Which team owns each affected service? Did its issue land in the right project, with an issue type that project accepts?
Blockers
A team is waiting on a base image or a vendor patch. You hear about it in the weekly sync, days after it happened.
Inactivity
Issues sit in To Do with no comment for a week. Jira will not tell you which ones unless you build and rerun the filter.
Reminders
You chase the same owners by hand every few days until the patch window closes.
Deadline risk
Leadership asks whether you will meet the remediation SLA. You rebuild the answer from JQL and a spreadsheet.
Evidence
Afterwards someone asks who launched the work, who approved it, and when each team was reminded.
One view of the remediation. Jira stays the system of record.
Every affected team gets its issue
One launch creates a remediation issue in each owning team's Jira project, as a sub-task, epic child or linked issue depending on what that project supports.
You can see who is left
Completion rolls up across teams. Done, in-progress, blocked and stale work is visible in one place.
Stale and blocked work is flagged
Issues with no update past your threshold are flagged, and so are comments that mention a blocker.
Follow-up runs on a schedule
Auto-nudge comments on idle issues once a day. You can also nudge every pending team in one action.
Large launches need approval
Require an approver before a launch above a team-count threshold creates anything.
A record you can export
Launches, approvals, nudges and recalls are written to an audit log kept for 180 days and exportable as CSV.
From advisory to all teams done, in four steps.
Map teams once
Add owning teams and their Jira projects, by hand or from CSV. Armada checks project access and issue types before you launch.
Write the fix once
Describe the vulnerability, affected versions, the fix and the deadline in one parent Jira issue.
Launch to affected teams
Select the teams that run affected services. Armada creates their issues and reports any team it could not reach, with the reason.
Track and follow up
Watch completion, follow up with blocked and stale teams, and close the parent when every team is done.
Illustration: one vulnerability, 40 services, 14 days
A security advisory lands on Monday. The AppSec lead writes one parent issue with the advisory, the fixed version and a 14-day deadline, then launches it to the 40 teams whose services use the library.
By Wednesday, most teams have picked up their issue. Six have not touched it. Auto-nudge comments on those six issues each morning, so the owners get a Jira notification without anyone writing a message.
On day nine, one team comments that it is blocked on a base image. That issue is flagged as blocked in the roll-up, so the AppSec lead escalates to the platform team the same day instead of finding out in the next status meeting.
When the last team closes its issue, the parent shows 100% complete, and the audit log shows who launched the remediation, who approved it, and when each reminder went out.
What you will see in Armada
Armada runs inside Jira Cloud. Every team's work stays a normal Jira issue in its own project and workflow. These are the names Armada uses for the parts above.
- Campaign
- One initiative, such as this remediation, tracked from its parent Jira issue.
- Fleet
- Your list of teams and their Jira projects, reused for every campaign.
- Launch
- Creating every participating team's issue in one action, after a pre-launch check.
- Mission Control and SITREP
- The roll-up of every team issue, with a situation report of blocked, stale and at-risk work.
- Auto-nudge
- Scheduled reminder comments on issues that have gone idle.
- Recall
- Withdraw a launch: delete the team issues where permitted, otherwise close or unlink them.
Before you install
Does Armada scan for vulnerabilities?
No. Armada coordinates the remediation work in Jira. Your scanner or advisory tells you what is affected; Armada gets the fix to every owning team and tracks it to done.
Do teams have to change their Jira workflow?
No. Each team gets a normal Jira issue in its own project and works it through its existing workflow. Armada reads status from those issues.
What if a team uses a different project setup or issue type?
Armada chooses how to create each team's issue (sub-task, epic child or linked issue) based on the parent and the target project, and checks issue type availability before launch.
Where is the data stored?
Armada is built on Atlassian Forge. Campaign data is stored in Atlassian's Forge storage for your site, and Armada runs no servers of its own.
How many teams can one remediation cover?
Armada is built for initiatives that span dozens of teams. Launches are created in batches to stay within Jira rate limits.
Run your next remediation from one place.
Install Armada, add the teams that own affected services, and launch the remediation from its parent Jira issue.
Free 30-day trial through the Atlassian Marketplace. Jira Cloud only.